Re: [IronPython] Creating Dynamic Assemblies from IronPython 2.6

[Curt Hagenlocher]

It's not quite that straightforward with p/Invoke though -- it can be *very*
convenient to define multiple overloads for the same C function with
different signatures. Consider the GetPrinter function and the different
versions of the PRINTER_INFO_x structure it can deal with:

http://msdn.microsoft.com/en-us/library/dd144911(VS.85).aspx
On Mon, Mar 23, 2009 at 4:21 PM, Jeff Hardy  wrote:

> I've been thinking about whether that functionality is really needed.
> C doesn't support function overloading, so presumably there would only
> ever by one signature per name? I'll have to see if CPython supports
> that.
>
> - Jeff
>
> 2009/3/23 Curt Hagenlocher :
> > I seem to recall that in Seo's original code, MakeOrAdd was used to build
> up
> > the overloads over time as user code asked for additional method
> signatures
> > for the same method name.  This could presumably be simulated by
> replacing
> > the method group in Python with a new method group that contained all the
> > original infos plus the new one.
> >
> > On Mon, Mar 23, 2009 at 11:11 AM, Dino Viehland 
> wrote:
> >>
> >> Do you actually need MakeOrAdd or would the factory that takes multiple
> >> method infos be good enough?
> >>
> >> I'm just reluctant to open up the ability to modify any built-in
> function.
> >>
> >> > -Original Message-
> >> > From: users-boun...@lists.ironpython.com [mailto:users-
> >> > boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> >> > Sent: Saturday, March 21, 2009 1:17 PM
> >> > To: Discussion of IronPython
> >> > Subject: Re: [IronPython] Creating Dynamic Assemblies from IronPython
> >> > 2.6
> >> >
> >> > Hi Dino,
> >> > I'm updating Seo's old ctypes.py to work with 2.6, so unfortuantely
> >> > it's a little more complex than just one method. I could probably use
> >> > a delegate that takes an object[], but BuiltinFunction contains that
> >> > code already, and it is a lot more optimized than I could manage. Plus
> >> > it's less code for me to write :).
> >> >
> >> > - Jeff
> >> >
> >> > On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland 
> >> > wrote:
> >> > > If you only have 1 method and don't need overload resolution I'd
> >> > suggest making a delegate using System.Delegate.CreateDelegate.
> >> > Otherwise this could be made public.
> >> > >
> >> > ___
> >> > Users mailing list
> >> > Users@lists.ironpython.com
> >> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >> ___
> >> Users mailing list
> >> Users@lists.ironpython.com
> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Creating Dynamic Assemblies from IronPython 2.6

[Jeff Hardy]

I've been thinking about whether that functionality is really needed.
C doesn't support function overloading, so presumably there would only
ever by one signature per name? I'll have to see if CPython supports
that.

- Jeff

2009/3/23 Curt Hagenlocher :
> I seem to recall that in Seo's original code, MakeOrAdd was used to build up
> the overloads over time as user code asked for additional method signatures
> for the same method name.  This could presumably be simulated by replacing
> the method group in Python with a new method group that contained all the
> original infos plus the new one.
>
> On Mon, Mar 23, 2009 at 11:11 AM, Dino Viehland  wrote:
>>
>> Do you actually need MakeOrAdd or would the factory that takes multiple
>> method infos be good enough?
>>
>> I'm just reluctant to open up the ability to modify any built-in function.
>>
>> > -Original Message-
>> > From: users-boun...@lists.ironpython.com [mailto:users-
>> > boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
>> > Sent: Saturday, March 21, 2009 1:17 PM
>> > To: Discussion of IronPython
>> > Subject: Re: [IronPython] Creating Dynamic Assemblies from IronPython
>> > 2.6
>> >
>> > Hi Dino,
>> > I'm updating Seo's old ctypes.py to work with 2.6, so unfortuantely
>> > it's a little more complex than just one method. I could probably use
>> > a delegate that takes an object[], but BuiltinFunction contains that
>> > code already, and it is a lot more optimized than I could manage. Plus
>> > it's less code for me to write :).
>> >
>> > - Jeff
>> >
>> > On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland 
>> > wrote:
>> > > If you only have 1 method and don't need overload resolution I'd
>> > suggest making a delegate using System.Delegate.CreateDelegate.
>> > Otherwise this could be made public.
>> > >
>> > ___
>> > Users mailing list
>> > Users@lists.ironpython.com
>> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Two Problems with sys.argv and compiled scripts

[Michael Foord]

Bruce Bromberek wrote:
So if I follow your lead at 
http://www.voidspace.org.uk/ironpython/custom_executable.shtml


it looks like I need to modify this code to call my complied DLL 
instead of the pythonsource code?

string path = Path.Combine(
Path.GetDirectoryName(Application.ExecutablePath),
  "main.py");
engine.ExecuteFile(path);

  
Is that right?  My end goal it to produce an exe that I can wrap up 
into an installer and distribute to people without ironpython installed.


Once I get a working example, I'll post a detailed explanation back to 
this group for the benefit of the others coping with the transition 
from IronPython 1.0 to 2.0.




That article is for IronPython 1 as it says at the start. It sounds like 
that is what you want.


If you want IronPython 2 then you are better off with this article:

http://www.voidspace.org.uk/ironpython/hosting_api.shtml

All the best,

Michael Foord



Thanks in advance


-WombatPM

PS  If you tell me that your book has all of the detail, I'll get the 
early access version ASAP.





On Mon, Mar 23, 2009 at 4:16 PM, Michael Foord 
mailto:fuzzy...@voidspace.org.uk>> wrote:


Bruce Bromberek wrote:

Problem #1
I know this is a know issue, but my google-fu has been able to
uncover the solution.  When I compile my script into an exe ,
sys.argv get sets to ' '.

Using SharpDevelop and Ironpython 2.0.1

#Program.py
#
import clr
clr.AddReference('mscorlib')
clr.AddReference('System')
import sys
import System

if __name__ == 'Program':
   try:
   print "sys.argv = ",sys.argv
   except System.Exception, e:
   print e

yeilds output of
C:\Program Files\IronPython 2.0.1\Samples\pyc>Program.exe fred
sys.argv =  ['']

instead of the expected
sys.argv['fred']

Problem #2:

If I drag and drop a file onto the exe, I get a exception
message that I can't see.  In IronPython 1.0, the dropped file
would populate sys.argv

Hopefully someone can answer or direct me to better source.



Creating a custom C# executable that embeds the IronPython engine,
starts your application, and populates sys.argv is the best
workaround for these problems.

Michael


-WombatPM




___
Users mailing list
Users@lists.ironpython.com 
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
 




-- 
http://www.ironpythoninaction.com/

http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com 
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Two Problems with sys.argv and compiled scripts

[Bruce Bromberek]

So if I follow your lead at
http://www.voidspace.org.uk/ironpython/custom_executable.shtml

it looks like I need to modify this code to call my complied DLL instead of
the pythonsource code?

string path = Path.Combine(
Path.GetDirectoryName(Application.ExecutablePath),
  "main.py");
engine.ExecuteFile(path);

Is that right?  My end goal it to produce an exe that I can wrap up into an
installer and distribute to people without ironpython installed.

Once I get a working example, I'll post a detailed explanation back to this
group for the benefit of the others coping with the transition from
IronPython 1.0 to 2.0.


Thanks in advance


-WombatPM

PS  If you tell me that your book has all of the detail, I'll get the early
access version ASAP.




On Mon, Mar 23, 2009 at 4:16 PM, Michael Foord wrote:

> Bruce Bromberek wrote:
>
>> Problem #1
>> I know this is a know issue, but my google-fu has been able to uncover the
>> solution.  When I compile my script into an exe , sys.argv get sets to ' '.
>>
>> Using SharpDevelop and Ironpython 2.0.1
>>
>> #Program.py
>> #
>> import clr
>> clr.AddReference('mscorlib')
>> clr.AddReference('System')
>> import sys
>> import System
>>
>> if __name__ == 'Program':
>>try:
>>print "sys.argv = ",sys.argv
>>except System.Exception, e:
>>print e
>>
>> yeilds output of
>> C:\Program Files\IronPython 2.0.1\Samples\pyc>Program.exe fred
>> sys.argv =  ['']
>>
>> instead of the expected
>> sys.argv['fred']
>>
>> Problem #2:
>>
>> If I drag and drop a file onto the exe, I get a exception message that I
>> can't see.  In IronPython 1.0, the dropped file would populate sys.argv
>>
>> Hopefully someone can answer or direct me to better source.
>>
>
>
> Creating a custom C# executable that embeds the IronPython engine, starts
> your application, and populates sys.argv is the best workaround for these
> problems.
>
> Michael
>
>
>> -WombatPM
>>
>>
>> 
>>
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Creating Dynamic Assemblies from IronPython 2.6

[Dino Viehland]

Maybe we could add a BuiltinFunctionBuild which provided this functionality.  
Then as long as the creator holds onto the BFB they can continue to mutate the 
function w/o allowing anyone else to.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Monday, March 23, 2009 3:43 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Creating Dynamic Assemblies from IronPython 2.6

I seem to recall that in Seo's original code, MakeOrAdd was used to build up 
the overloads over time as user code asked for additional method signatures for 
the same method name.  This could presumably be simulated by replacing the 
method group in Python with a new method group that contained all the original 
infos plus the new one.
On Mon, Mar 23, 2009 at 11:11 AM, Dino Viehland 
mailto:di...@microsoft.com>> wrote:
Do you actually need MakeOrAdd or would the factory that takes multiple method 
infos be good enough?

I'm just reluctant to open up the ability to modify any built-in function.

> -Original Message-
> From: 
> users-boun...@lists.ironpython.com 
> [mailto:users-
> boun...@lists.ironpython.com] On Behalf 
> Of Jeff Hardy
> Sent: Saturday, March 21, 2009 1:17 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Creating Dynamic Assemblies from IronPython
> 2.6
>
> Hi Dino,
> I'm updating Seo's old ctypes.py to work with 2.6, so unfortuantely
> it's a little more complex than just one method. I could probably use
> a delegate that takes an object[], but BuiltinFunction contains that
> code already, and it is a lot more optimized than I could manage. Plus
> it's less code for me to write :).
>
> - Jeff
>
> On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland 
> mailto:di...@microsoft.com>>
> wrote:
> > If you only have 1 method and don't need overload resolution I'd
> suggest making a delegate using System.Delegate.CreateDelegate.
> Otherwise this could be made public.
> >
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Creating Dynamic Assemblies from IronPython 2.6

[Curt Hagenlocher]

I seem to recall that in Seo's original code, MakeOrAdd was used to build up
the overloads over time as user code asked for additional method signatures
for the same method name.  This could presumably be simulated by replacing
the method group in Python with a new method group that contained all the
original infos plus the new one.

On Mon, Mar 23, 2009 at 11:11 AM, Dino Viehland  wrote:

> Do you actually need MakeOrAdd or would the factory that takes multiple
> method infos be good enough?
>
> I'm just reluctant to open up the ability to modify any built-in function.
>
> > -Original Message-
> > From: users-boun...@lists.ironpython.com [mailto:users-
> > boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> > Sent: Saturday, March 21, 2009 1:17 PM
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] Creating Dynamic Assemblies from IronPython
> > 2.6
> >
> > Hi Dino,
> > I'm updating Seo's old ctypes.py to work with 2.6, so unfortuantely
> > it's a little more complex than just one method. I could probably use
> > a delegate that takes an object[], but BuiltinFunction contains that
> > code already, and it is a lot more optimized than I could manage. Plus
> > it's less code for me to write :).
> >
> > - Jeff
> >
> > On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland 
> > wrote:
> > > If you only have 1 method and don't need overload resolution I'd
> > suggest making a delegate using System.Delegate.CreateDelegate.
> > Otherwise this could be made public.
> > >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Two Problems with sys.argv and compiled scripts

[Michael Foord]

Bruce Bromberek wrote:

Problem #1
I know this is a know issue, but my google-fu has been able to uncover 
the solution.  When I compile my script into an exe , sys.argv get 
sets to ' '.


Using SharpDevelop and Ironpython 2.0.1

#Program.py
#
import clr
clr.AddReference('mscorlib')
clr.AddReference('System')
import sys
import System

if __name__ == 'Program':
try:
print "sys.argv = ",sys.argv
except System.Exception, e:
print e

yeilds output of
C:\Program Files\IronPython 2.0.1\Samples\pyc>Program.exe fred
sys.argv =  ['']

instead of the expected
sys.argv['fred']

Problem #2:

If I drag and drop a file onto the exe, I get a exception message that 
I can't see.  In IronPython 1.0, the dropped file would populate sys.argv


Hopefully someone can answer or direct me to better source.



Creating a custom C# executable that embeds the IronPython engine, 
starts your application, and populates sys.argv is the best workaround 
for these problems.


Michael



-WombatPM




___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Two Problems with sys.argv and compiled scripts

[Bruce Bromberek]

Problem #1
I know this is a know issue, but my google-fu has been able to uncover the
solution.  When I compile my script into an exe , sys.argv get sets to ' '.

Using SharpDevelop and Ironpython 2.0.1

#Program.py
#
import clr
clr.AddReference('mscorlib')
clr.AddReference('System')
import sys
import System

if __name__ == 'Program':
try:
print "sys.argv = ",sys.argv
except System.Exception, e:
print e

yeilds output of
C:\Program Files\IronPython 2.0.1\Samples\pyc>Program.exe fred
sys.argv =  ['']

instead of the expected
sys.argv['fred']

Problem #2:

If I drag and drop a file onto the exe, I get a exception message that I
can't see.  In IronPython 1.0, the dropped file would populate sys.argv

Hopefully someone can answer or direct me to better source.

-WombatPM
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Creating Dynamic Assemblies from IronPython 2.6

[Dino Viehland]

Do you actually need MakeOrAdd or would the factory that takes multiple method 
infos be good enough? 

I'm just reluctant to open up the ability to modify any built-in function.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Saturday, March 21, 2009 1:17 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Creating Dynamic Assemblies from IronPython
> 2.6
> 
> Hi Dino,
> I'm updating Seo's old ctypes.py to work with 2.6, so unfortuantely
> it's a little more complex than just one method. I could probably use
> a delegate that takes an object[], but BuiltinFunction contains that
> code already, and it is a lot more optimized than I could manage. Plus
> it's less code for me to write :).
> 
> - Jeff
> 
> On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland 
> wrote:
> > If you only have 1 method and don't need overload resolution I'd
> suggest making a delegate using System.Delegate.CreateDelegate.
> Otherwise this could be made public.
> >
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] memory leak in IP 2.0.1

[Dody Gunawinata]

There is a bug item for this memory leak issue

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399

2009/3/23 Zsidó Zoltán 

> Hello,
>
> I host ironPython in c#. It worked well. I changed from 1.1.2 to 2.0.1 and
> now I have a memory leak.
>
> I do not know why. Any idea?
>
> I do not know the working of DLR but is there a GenerateCodeSnippet option
> in IP2.0.1 too?
>
> Perhaps it causes the memory leak.
>
> Thanks,
>
> Zoltan
>
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
nomadlife.org
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] memory leak in IP 2.0.1

[Dody Gunawinata]

This was response from Dino a couple of emails ago. Direct quote
"

ust some comments on this as there’s a few issues intertwined here:

1.   Optimized code – this is currently the default and part of the
original problem.  If you execute code in “optimized” mode we generate an
uncollectible type.  In 2.6 I’m switching the default to be non-optimized
and I also am trying out a change that should reduce the amount of leakage
when we do this.  That will make the out of the box experience much better.

2.   Multiple script runtimes – there’s a bug in the DLR when you
repeatedly create script runtimes that the rules aren’t getting collected.
This is supposed to be fixed in 2.6 but I’m still seeing some leaks in this
scenario that I’ll look into and fix.  Back-porting this to 2.0 would be
quite difficult as a lot of things have changed but we could certainly look
at backporting a different fix to 2.0.

3.   There’s a repro that defines “TestScriptOldClass” + n which leaks.
All class / function / member names in code get interned and this is where
this leak is coming from.  If you remove the + n then everything works.  We
may get rid of this interning at some point in the future but it’s a fairly
significant change.  I’m inclined to believe this one isn’t as much of an
issue as usually you aren’t compiling code with new names every single
type.

"


2009/3/23 Zsidó Zoltán 

> Hello,
>
> I host ironPython in c#. It worked well. I changed from 1.1.2 to 2.0.1 and
> now I have a memory leak.
>
> I do not know why. Any idea?
>
> I do not know the working of DLR but is there a GenerateCodeSnippet option
> in IP2.0.1 too?
>
> Perhaps it causes the memory leak.
>
> Thanks,
>
> Zoltan
>
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
nomadlife.org
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] memory leak in IP 2.0.1

[Zsidó Zoltán]

Hello,

I host ironPython in c#. It worked well. I changed from 1.1.2 to 2.0.1 and 
now I have a memory leak.


I do not know why. Any idea?

I do not know the working of DLR but is there a GenerateCodeSnippet option 
in IP2.0.1 too?


Perhaps it causes the memory leak.

Thanks,

Zoltan


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com