Re: [IronPython] Embedding Question
Another alternative is:
ClrModule clr = (ClrModule)engine.Import("clr");
clr.AddReference(typeof(SomeAutoCadType).Assembly);
This is similar to doing
"engine.LoadAssembly(typeof(SomeAutoCadType).Assembly)", but is more robust
since it also updates "clr.References". PythonEngine.LoadAssembly should be
deprecated in favor of ClrModule.AddReference.
Shri
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Slide
Sent: Thursday, August 10, 2006 3:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
There is also an Import method on the PythonEngine object that allows you to
import stuff programatically as well.
On 8/10/06, Kristof Wagemans <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Isn't engine.LoadAssembly(typeof(SomeAutoCadType).Assembly)
> easier or is this different in some way?
>
>
>
>
>
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
> Sent: Thursday 10 August 2006 21:17
>
> To: Discussion of IronPython
> Subject: Re: [IronPython] Embedding Question
>
>
>
>
>
>
>
> Cool, looks like I was only close though J You may have already
> imported clr into the default module, but just for the record for
> those who haven't you'll need an import clr there. I just realized I forgot
> it the 1st time,
> and I had a redundant "AddReference" in the delegate call. I'm assuming
> you just fixed all that up, but just in case anyone else needs to do
> something like this, here's the correct code:
>
>
>
> delegate void AddReference(object assembly);
>
> AddReference adr = engine.CreateMethod("import
> clr\nclr.AddReference(assembly)");
>
> adr(typeof(SomeAutoCadType).Assembly);
>
>
>
> ___
> 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] PythonEngine.RunFile
__name___ == "__main__": is a convention enforced by ipy.exe. The PythonEngine itself does not directly support this concept. However, you can achieve that result (just like ipy.exe does) by using code like this: PythonEngine engine = new PythonEngine(); EngineModule module = engine.CreateModule(“__main__”, false); engine.ExecuteFile(filename, module); Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Maly Sent: Thursday, August 10, 2006 3:06 PM To: Discussion of IronPython Subject: Re: [IronPython] PythonEngine.RunFile You can try the PythonEngine.CreateOptimizedModule which you can also pass a name your module should get. Let us know if that doesn’t meet your needs. Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Riley Sent: Thursday, August 10, 2006 2:17 PM To: Discussion of IronPython Subject: Re: [IronPython] PythonEngine.RunFile I've tested that and I don't think it works with: if __name___ == "__main__": in the python script. Regards, Tim Riley On 8/10/06, Martin Maly <[EMAIL PROTECTED]> wrote: Think PythonEngine.ExecuteFile may work for you. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tim Riley Sent: Thursday, August 10, 2006 1:01 PM To: Discussion of IronPython Subject: [IronPython] PythonEngine.RunFile In IP version 0.9 there was a PythonEngine.RunFile() method, this seems to be gone in 1.0.6. Is there a replacement? ___ 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] Debugging support PythonEngine
If EngineOptions.ClrDebuggingEnabled is set, we use AssemblyBuilder, TypeBuilder, etc for PythonEngine.Executed. The code generated by AssemblyBuilder, TypeBuilder, etc supports PDB debug information tracking for the methods, and so you will be able to set breakpoints in the code. However, it does not guarantee a perfect debugging experience. PythonEngine.ExecuteFile will use a dictionary for storing global variables, and these will not be visible because VS does not know about the dictionary. If you use PythonEngine.CreateOptimizedModule, most global variables are implemented using CLR statics, and so VS may be able to display them for you. Global variables added using an exec statement will still not be visible. If EngineOptions.ClrDebuggingEnabled is false, we will use System.Reflection.Emit.DynamicMethod. This does not support debug information tracking at all, and you will not even be able to see function variables. So If EngineOptions.ClrDebuggingEnabled is will improve your debugging experience, but it wont give you a perfect experience. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Thursday, August 10, 2006 2:10 PM To: Discussion of IronPython Subject: [IronPython] Debugging support PythonEngine I have been experimenting with the debugging support for the PythonEngine. When I use the following code I have several problems. PythonEngine _pe; EngineOptions options = new EngineOptions(); options.ClrDebuggingEnabled = true; _pe = new PythonEngine(options); _pe.ExecuteFile(@"
Re: [IronPython] PythonEngine.RunFile
You can try the PythonEngine.CreateOptimizedModule which you can also pass a name your module should get. Let us know if that doesn’t meet your needs. Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Riley Sent: Thursday, August 10, 2006 2:17 PM To: Discussion of IronPython Subject: Re: [IronPython] PythonEngine.RunFile I've tested that and I don't think it works with: if __name___ == "__main__": in the python script. Regards, Tim Riley On 8/10/06, Martin Maly <[EMAIL PROTECTED]> wrote: Think PythonEngine.ExecuteFile may work for you. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tim Riley Sent: Thursday, August 10, 2006 1:01 PM To: Discussion of IronPython Subject: [IronPython] PythonEngine.RunFile In IP version 0.9 there was a PythonEngine.RunFile() method, this seems to be gone in 1.0.6. Is there a replacement? ___ 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] Embedding Question
There is also an Import method on the PythonEngine object that allows
you to import stuff programatically as well.
On 8/10/06, Kristof Wagemans <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Isn't engine.LoadAssembly(typeof(SomeAutoCadType).Assembly)
> easier or is this different in some way?
>
>
>
>
>
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Dino Viehland
> Sent: Thursday 10 August 2006 21:17
>
> To: Discussion of IronPython
> Subject: Re: [IronPython] Embedding Question
>
>
>
>
>
>
>
> Cool, looks like I was only close though J You may have already imported clr
> into the default module, but just for the record for those who haven't
> you'll need an import clr there. I just realized I forgot it the 1st time,
> and I had a redundant "AddReference" in the delegate call. I'm assuming
> you just fixed all that up, but just in case anyone else needs to do
> something like this, here's the correct code:
>
>
>
> delegate void AddReference(object assembly);
>
> AddReference adr = engine.CreateMethod("import
> clr\nclr.AddReference(assembly)");
>
> adr(typeof(SomeAutoCadType).Assembly);
>
>
>
> ___
> 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] Embedding Question
Isn’t engine.LoadAssembly(typeof(SomeAutoCadType).Assembly)
easier or is this different in some way?
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Thursday 10 August 2006
21:17
To: Discussion
of IronPython
Subject: Re: [IronPython]
Embedding Question
Cool, looks like I
was only close though J You may have already imported clr into the default
module, but just for the record for those who haven’t you’ll need
an import clr there. I just realized I forgot it the 1st time,
and I had a redundant “AddReference” in the delegate call.
I’m assuming you just fixed all that up, but just in case anyone
else needs to do something like this, here’s the correct code:
delegate void AddReference(object assembly);
AddReference adr =
engine.CreateMethod("import
clr\nclr.AddReference(assembly)");
adr(typeof(SomeAutoCadType).Assembly);
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] PythonEngine.RunFile
I've tested that and I don't think it works with:if __name___ == "__main__":in the python script.Regards,Tim RileyOn 8/10/06, Martin Maly <[EMAIL PROTECTED]> wrote: Think PythonEngine.ExecuteFile may work for you. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tim Riley Sent: Thursday, August 10, 2006 1:01 PM To: Discussion of IronPython Subject: [IronPython] PythonEngine.RunFile In IP version 0.9 there was a PythonEngine.RunFile() method, this seems to be gone in 1.0.6. Is there a replacement? ___users mailing listusers@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
[IronPython] Debugging support PythonEngine
I have been experimenting with the debugging support for the PythonEngine. When I use the following code I have several problems. PythonEngine _pe; EngineOptions options = new EngineOptions(); options.ClrDebuggingEnabled = true; _pe = new PythonEngine(options); _pe.ExecuteFile(@"
Re: [IronPython] PythonEngine.RunFile
Think PythonEngine.ExecuteFile may work for you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Riley Sent: Thursday, August 10, 2006 1:01 PM To: Discussion of IronPython Subject: [IronPython] PythonEngine.RunFile In IP version 0.9 there was a PythonEngine.RunFile() method, this seems to be gone in 1.0.6. Is there a replacement? ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Embedding Question
Thanks Dino. I had figured that out.On 8/10/06, Dino Viehland <[EMAIL PROTECTED]> wrote:
Cool, looks like I was only close though J
You
may have already imported clr into the default module, but just for the record
for those who haven't you'll need an import clr there. I just realized I
forgot it the 1st time, and I had a redundant "AddReference" in the
delegate call. I'm assuming you just fixed all that up, but just in case
anyone else needs to do something like this, here's the correct code:
delegate void
AddReference(object assembly);
AddReference adr =
engine.CreateMethod("import clr\nclr.AddReference(assembly)");
adr(typeof(SomeAutoCadType).Assembly);
From:
[EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On
Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 12:10 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
That's exactly what I needed.
Thank you Dino.
On 8/10/06, Dino Viehland <[EMAIL PROTECTED]
> wrote:
You can get the assembly object
from an AutoCAD type: typeof(Foo).Assembly. From there you just need to
have one helper which will register this in the engine, so you could do:
delegate void
AddReference(object assembly);
AddReference adr =
engine.CreateMethod("clr.AddReference(assembly)");
adr.AddReference(typeof(SomeAutoCadType).Assembly);
and then from there you should
be able to import any of the AutoCAD namespaces from any of your modules.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:40 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
What I'm trying to do is sort of weird so let
me see if I can elaborate further. I am embedding IronPython in a .NET assembly
that will later be loaded into AutoCAD. AutoCAD has their own two .NET
assemblies that must be referenced, " acmgd.dll" and
"acdbmgd.dll". These two assemblies are always loaded while AutoCAD
is running so their location isn't really a concern when creating a C# .dll.
However when I want to modify AutoCAD entities from within my IP scripts I must
first load the assemblies from file and path which is a problem because the
file and path are different with each different version of AutoCAD.
For example their path in my AutoCAD Mechanical 2005 is 'C:\Program
Files\Autodesk\Acadm 2005' but with regular AutoCAD it would be 'C:\Program
Files\Autodesk\Acad 2005'. There are so many different variations that this
path could be that it would be a big deal to try/except load them all from some
sort of init script.
So basically I'm looking to pass a non-GAC assembly reference from my C#
project to my IP project.
Note: I'm fine with the import statements.
On 8/10/06, Dino Viehland <[EMAIL PROTECTED]>
wrote:
Adding references updates the
entire engine, it's not local to just the current module. So once you
have added a reference you just need to import the namespace into any given
module.
Were you also trying to avoid
the import statements?
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:02 AM
To: Discussion of IronPython
Subject: [IronPython] Embedding Question
If I have an embedded project can I automatically make .NET assemblies
referenced in the project available to my python scripts? For example I have
two assemblies(not in the GAC) that I have referenced in my project. I would like
them always available to all python files run from this program without having
to do the import clr, clr.AddReferenceToFileAndPath('blah') stuff in the
beginning of each file. Is this possible?
Regards,
Tim Riley
___
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 listusers@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
[IronPython] PythonEngine.RunFile
In IP version 0.9 there was a PythonEngine.RunFile() method, this seems to be gone in 1.0.6. Is there a replacement? ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Embedding Question
Cool, looks like I was only close though J You
may have already imported clr into the default module, but just for the record
for those who haven’t you’ll need an import clr there. I just realized I
forgot it the 1st time, and I had a redundant “AddReference” in the
delegate call. I’m assuming you just fixed all that up, but just in case
anyone else needs to do something like this, here’s the correct code:
delegate void
AddReference(object assembly);
AddReference adr =
engine.CreateMethod("import clr\nclr.AddReference(assembly)");
adr(typeof(SomeAutoCadType).Assembly);
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 12:10 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
That's exactly what I needed.
Thank you Dino.
On 8/10/06, Dino Viehland <[EMAIL PROTECTED]
> wrote:
You can get the assembly object
from an AutoCAD type: typeof(Foo).Assembly. From there you just need to
have one helper which will register this in the engine, so you could do:
delegate void
AddReference(object assembly);
AddReference adr =
engine.CreateMethod("clr.AddReference(assembly)");
adr.AddReference(typeof(SomeAutoCadType).Assembly);
and then from there you should
be able to import any of the AutoCAD namespaces from any of your modules.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:40 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
What I'm trying to do is sort of weird so let
me see if I can elaborate further. I am embedding IronPython in a .NET assembly
that will later be loaded into AutoCAD. AutoCAD has their own two .NET
assemblies that must be referenced, " acmgd.dll" and
"acdbmgd.dll". These two assemblies are always loaded while AutoCAD
is running so their location isn't really a concern when creating a C# .dll.
However when I want to modify AutoCAD entities from within my IP scripts I must
first load the assemblies from file and path which is a problem because the
file and path are different with each different version of AutoCAD.
For example their path in my AutoCAD Mechanical 2005 is 'C:\Program
Files\Autodesk\Acadm 2005' but with regular AutoCAD it would be 'C:\Program
Files\Autodesk\Acad 2005'. There are so many different variations that this
path could be that it would be a big deal to try/except load them all from some
sort of init script.
So basically I'm looking to pass a non-GAC assembly reference from my C#
project to my IP project.
Note: I'm fine with the import statements.
On 8/10/06, Dino Viehland <[EMAIL PROTECTED]>
wrote:
Adding references updates the
entire engine, it's not local to just the current module. So once you
have added a reference you just need to import the namespace into any given
module.
Were you also trying to avoid
the import statements?
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:02 AM
To: Discussion of IronPython
Subject: [IronPython] Embedding Question
If I have an embedded project can I automatically make .NET assemblies
referenced in the project available to my python scripts? For example I have
two assemblies(not in the GAC) that I have referenced in my project. I would like
them always available to all python files run from this program without having
to do the import clr, clr.AddReferenceToFileAndPath('blah') stuff in the
beginning of each file. Is this possible?
Regards,
Tim Riley
___
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] Embedding Question
That's exactly what I needed. Thank you Dino.On 8/10/06, Dino Viehland <[EMAIL PROTECTED]
> wrote:
You can get the assembly object from an AutoCAD type:
typeof(Foo).Assembly. From there you just need to have one helper which
will register this in the engine, so you could do:
delegate void AddReference(object assembly);
AddReference adr = engine.CreateMethod("clr.AddReference(assembly)");
adr.AddReference(typeof(SomeAutoCadType).Assembly);
and then from there you should be able to import any of the AutoCAD
namespaces from any of your modules.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:40 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
What I'm trying to do is sort
of weird so let me see if I can elaborate further. I am embedding IronPython in
a .NET assembly that will later be loaded into AutoCAD. AutoCAD has their own
two .NET assemblies that must be referenced, " acmgd.dll" and
"acdbmgd.dll". These two assemblies are always loaded while AutoCAD
is running so their location isn't really a concern when creating a C# .dll.
However when I want to modify AutoCAD entities from within my IP scripts I must
first load the assemblies from file and path which is a problem because the
file and path are different with each different version of AutoCAD.
For example their path in my AutoCAD Mechanical 2005 is 'C:\Program
Files\Autodesk\Acadm 2005' but with regular AutoCAD it would be 'C:\Program
Files\Autodesk\Acad 2005'. There are so many different variations that this
path could be that it would be a big deal to try/except load them all from some
sort of init script.
So basically I'm looking to pass a non-GAC assembly reference from my C#
project to my IP project.
Note: I'm fine with the import statements.
On 8/10/06, Dino Viehland <[EMAIL PROTECTED]>
wrote:
Adding references updates the
entire engine, it's not local to just the current module. So once you
have added a reference you just need to import the namespace into any given
module.
Were you also trying to avoid
the import statements?
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:02 AM
To: Discussion of IronPython
Subject: [IronPython] Embedding Question
If I have an embedded project can I automatically make .NET assemblies
referenced in the project available to my python scripts? For example I have
two assemblies(not in the GAC) that I have referenced in my project. I would
like them always available to all python files run from this program without
having to do the import clr, clr.AddReferenceToFileAndPath('blah') stuff in the
beginning of each file. Is this possible?
Regards,
Tim Riley
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___users mailing listusers@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] Embedding Question
You can get the assembly object from an AutoCAD type:
typeof(Foo).Assembly. From there you just need to have one helper which
will register this in the engine, so you could do:
delegate void AddReference(object assembly);
AddReference adr = engine.CreateMethod(“clr.AddReference(assembly)”);
adr.AddReference(typeof(SomeAutoCadType).Assembly);
and then from there you should be able to import any of the AutoCAD
namespaces from any of your modules.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:40 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding Question
What I'm trying to do is sort
of weird so let me see if I can elaborate further. I am embedding IronPython in
a .NET assembly that will later be loaded into AutoCAD. AutoCAD has their own
two .NET assemblies that must be referenced, " acmgd.dll" and
"acdbmgd.dll". These two assemblies are always loaded while AutoCAD
is running so their location isn't really a concern when creating a C# .dll.
However when I want to modify AutoCAD entities from within my IP scripts I must
first load the assemblies from file and path which is a problem because the
file and path are different with each different version of AutoCAD.
For example their path in my AutoCAD Mechanical 2005 is 'C:\Program
Files\Autodesk\Acadm 2005' but with regular AutoCAD it would be 'C:\Program
Files\Autodesk\Acad 2005'. There are so many different variations that this
path could be that it would be a big deal to try/except load them all from some
sort of init script.
So basically I'm looking to pass a non-GAC assembly reference from my C#
project to my IP project.
Note: I'm fine with the import statements.
On 8/10/06, Dino Viehland <[EMAIL PROTECTED]>
wrote:
Adding references updates the
entire engine, it's not local to just the current module. So once you
have added a reference you just need to import the namespace into any given
module.
Were you also trying to avoid
the import statements?
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:02 AM
To: Discussion of IronPython
Subject: [IronPython] Embedding Question
If I have an embedded project can I automatically make .NET assemblies
referenced in the project available to my python scripts? For example I have
two assemblies(not in the GAC) that I have referenced in my project. I would
like them always available to all python files run from this program without
having to do the import clr, clr.AddReferenceToFileAndPath('blah') stuff in the
beginning of each file. Is this possible?
Regards,
Tim Riley
___
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] Embedding Question
What I'm trying to do is sort of weird so let me see if I can elaborate further. I am embedding IronPython in a .NET assembly that will later be loaded into AutoCAD. AutoCAD has their own two .NET assemblies that must be referenced, "
acmgd.dll" and "acdbmgd.dll". These two assemblies are always loaded while AutoCAD is running so their location isn't really a concern when creating a C# .dll. However when I want to modify AutoCAD entities from within my IP scripts I must first load the assemblies from file and path which is a problem because the file and path are different with each different version of AutoCAD.
For example their path in my AutoCAD Mechanical 2005 is 'C:\Program Files\Autodesk\Acadm 2005' but with regular AutoCAD it would be 'C:\Program Files\Autodesk\Acad 2005'. There are so many different variations that this path could be that it would be a big deal to try/except load them all from some sort of init script.
So basically I'm looking to pass a non-GAC assembly reference from my C# project to my IP project.Note: I'm fine with the import statements.On 8/10/06,
Dino Viehland <[EMAIL PROTECTED]> wrote:
Adding references updates the entire engine, it's not local to
just the current module. So once you have added a reference you just need to
import the namespace into any given module.
Were you also trying to avoid the import statements?
From:
[EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On
Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:02 AM
To: Discussion of IronPython
Subject: [IronPython] Embedding Question
If I have an embedded project can I automatically make .NET
assemblies referenced in the project available to my python scripts? For
example I have two assemblies(not in the GAC) that I have referenced in my
project. I would like them always available to all python files run from this
program without having to do the import clr,
clr.AddReferenceToFileAndPath('blah') stuff in the beginning of each file. Is
this possible?
Regards,
Tim Riley
___users mailing listusers@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] Embedding Question
Adding references updates the entire engine, it’s not local to
just the current module. So once you have added a reference you just need to
import the namespace into any given module.
Were you also trying to avoid the import statements?
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tim Riley
Sent: Thursday, August 10, 2006 11:02 AM
To: Discussion of IronPython
Subject: [IronPython] Embedding Question
If I have an embedded project can I automatically make .NET
assemblies referenced in the project available to my python scripts? For
example I have two assemblies(not in the GAC) that I have referenced in my
project. I would like them always available to all python files run from this
program without having to do the import clr,
clr.AddReferenceToFileAndPath('blah') stuff in the beginning of each file. Is
this possible?
Regards,
Tim Riley
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Embedding Question
If I have an embedded project can I automatically make .NET assemblies referenced in the project available to my python scripts? For example I have two assemblies(not in the GAC) that I have referenced in my project. I would like them always available to all python files run from this program without having to do the import clr,
clr.AddReferenceToFileAndPath('blah') stuff in the beginning of each file. Is this possible?Regards,Tim Riley
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Bug of big integer manipulation
As for the infinite loop ... it is a bug in our PowMod code. It is not an actual infinite loop, but we just do the calculation very inefficiently. Filing as a bug also. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Maly Sent: Thursday, August 10, 2006 8:26 AM To: Discussion of IronPython Subject: Re: [IronPython] Bug of big integer manipulation This is a current limitation of IronPython implementation. I am filing it as a bug for us to seriously investigate. Thanks for your help with the repro! Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HEMMI, Shigeru Sent: Thursday, August 10, 2006 1:38 AM To: Discussion of IronPython Subject: Re: [IronPython] Bug of big integer manipulation Thanks for the answer. I was able to take a log with -X:ExceptionDetail, but since Japanese, log file includes Japanse characters; I removed them by hand. I was not able to which numbers were involved. The log file is attached. Please note that there are two problems; one is "ValueError: value too big" problem which we do not encounter with CPython. The other is an infinite loop bug. Please also note that NZMATH is pure python, having simple module structure and we will be able to duplicate the problem if you download it. Best regards, 2006/8/10, Martin Maly <[EMAIL PROTECTED]>: > By any chance, were you able to determine which operation caused the > exception and which numbers were involved? What would help me find out what > the problem is faster would be get a call stack (for that, could you please > run your repro with -X:ExceptionDetail switch? Then ideally if you could find > out what the big integer numbers were with which the operation failed, that > would be ideal. > > Thanks! > Martin > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of HEMMI, > Shigeru > Sent: Tuesday, August 08, 2006 4:31 PM > To: Discussion of IronPython > Subject: [IronPython] Bug of big integer manipulation > > Hello, > > NZMATH is a Python based number theory oriented calculation system developed > by Tokyo Metropolitan University. The URL is > http://tnt.math.metro-u.ac.jp/nzmath/. > > Using NZMATH, I encounterd a bug of big integer manipulation. > > IronPython > > C:\IronPython-2604>ipy > IronPython 1.0.2411 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. > All rights reserved. > >>> import sys > >>> sys.path.append(r'C:\Python24\Lib') > >>> sys.path.append(r'C:\Python24\Lib\site-packages') > >>> from nzmath import prime > >>> prime.nextPrime(256) > 257 > >>> nx = sys.maxint > >>> prime.nextPrime(nx*nx) > Traceback (most recent call last): > File , line 0, in ##115 > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 158, in nextPrime > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 206, in primeq > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 188, in smallSpsp > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 41, in spsp > ValueError: value too big > >>> prime.nextPrime(nx) ## Seems going into infinite loop. > > CPython > > C:\IronPython-2604>python > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > win32 Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> from nzmath import prime > >>> nx = sys.maxint > >>> prime.nextPrime(nx*nx) > 4611686014132420667L > >>> prime.nextPrime(nx) > 2147483659L > >>> > > Regards, > ___ > 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] Bug of big integer manipulation
This is a current limitation of IronPython implementation. I am filing it as a bug for us to seriously investigate. Thanks for your help with the repro! Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HEMMI, Shigeru Sent: Thursday, August 10, 2006 1:38 AM To: Discussion of IronPython Subject: Re: [IronPython] Bug of big integer manipulation Thanks for the answer. I was able to take a log with -X:ExceptionDetail, but since Japanese, log file includes Japanse characters; I removed them by hand. I was not able to which numbers were involved. The log file is attached. Please note that there are two problems; one is "ValueError: value too big" problem which we do not encounter with CPython. The other is an infinite loop bug. Please also note that NZMATH is pure python, having simple module structure and we will be able to duplicate the problem if you download it. Best regards, 2006/8/10, Martin Maly <[EMAIL PROTECTED]>: > By any chance, were you able to determine which operation caused the > exception and which numbers were involved? What would help me find out what > the problem is faster would be get a call stack (for that, could you please > run your repro with -X:ExceptionDetail switch? Then ideally if you could find > out what the big integer numbers were with which the operation failed, that > would be ideal. > > Thanks! > Martin > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of HEMMI, > Shigeru > Sent: Tuesday, August 08, 2006 4:31 PM > To: Discussion of IronPython > Subject: [IronPython] Bug of big integer manipulation > > Hello, > > NZMATH is a Python based number theory oriented calculation system developed > by Tokyo Metropolitan University. The URL is > http://tnt.math.metro-u.ac.jp/nzmath/. > > Using NZMATH, I encounterd a bug of big integer manipulation. > > IronPython > > C:\IronPython-2604>ipy > IronPython 1.0.2411 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. > All rights reserved. > >>> import sys > >>> sys.path.append(r'C:\Python24\Lib') > >>> sys.path.append(r'C:\Python24\Lib\site-packages') > >>> from nzmath import prime > >>> prime.nextPrime(256) > 257 > >>> nx = sys.maxint > >>> prime.nextPrime(nx*nx) > Traceback (most recent call last): > File , line 0, in ##115 > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 158, in nextPrime > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 206, in primeq > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 188, in smallSpsp > File C:\Python24\Lib\site-packages\nzmath\prime.py, line 41, in spsp > ValueError: value too big > >>> prime.nextPrime(nx) ## Seems going into infinite loop. > > CPython > > C:\IronPython-2604>python > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > win32 Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> from nzmath import prime > >>> nx = sys.maxint > >>> prime.nextPrime(nx*nx) > 4611686014132420667L > >>> prime.nextPrime(nx) > 2147483659L > >>> > > Regards, > ___ > 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] Bug of big integer manipulation
I wrote: The log file is attached. Sorry, "A non-text attachment was scrubbed..." occured. I resend the attachment file again with .txt extension. C:\NZMATH-0.5.1>dir 2006/08/10 17:28 . 2006/08/10 17:28 .. 2006/08/08 20:42 4,214 CHANGES.txt 2006/08/08 20:42 835 HISTORY.txt 2006/08/10 17:1661,440 ipy.exe 2006/08/10 17:1645,056 IronMath.dll 2006/08/10 17:16 1,527,808 IronPython.dll 2006/08/08 20:42 1,563 LICENSE.txt 2006/08/08 20:42 manual 2006/08/08 20:42 nzmath 2006/08/08 20:42 288 PKG-INFO 2006/08/08 20:42 1,916 README.txt 2006/08/08 20:42 5,466 setup.py 2006/08/08 20:42 5,428 tutorial.txt C:\NZMATH-0.5.1>ipy -X:ExceptionDetail IronPython 1.0.2413 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import sys >>> sys.path.append(r'C:\Python24\Lib') >>> from nzmath import prime >>> nx = sys.maxint >>> mx = nx*nx >>> mx 4611686014132420609L >>> prime.nextPrime(mx) value too big IronPython.Runtime.Operations.LongOps.PowerMod(BigInteger x, Object y, Object z) IronPython.Runtime.Operations.IntOps.PowerMod(Int32 x, Object y, Objectz) IronPython.Runtime.Operations.Ops.PowerMod(Object x, Object y, Object z) IronPython.Modules.Builtin.Pow(Object x, Object y, Object z) IronPython.Runtime.Calls.FastCallableAny.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) IronPython.Runtime.Calls.BuiltinFunction.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1, Object arg2) nzmath.prime.spsp$f1(Object n, Object base, Object s, Object t) C:\NZMATH-0.5.1\nzmath\prime.py:line 43 IronPython.Runtime.Calls.Function4.Call(ICallerContext context, Object arg0, Object arg1) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1) nzmath.prime.smallSpsp$f17(Object n) C:\NZMATH-0.5.1\nzmath\prime.py:line 278 IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0) nzmath.prime.primeq$f18(Object n) C:\NZMATH-0.5.1\nzmath\prime.py:line 297 IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0) nzmath.prime.nextPrime$f15(Object n) C:\NZMATH-0.5.1\nzmath\prime.py:line 246 IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0) ##114(ModuleScope ) IronPython.Hosting.CompiledCodeDelegate.Invoke(ModuleScope moduleScope) IronPython.Hosting.CompiledCode.Run(ModuleScope moduleScope) IronPython.Hosting.PythonEngine.ExecuteToConsole(String text, EngineModule engineModule, IDictionary`2 locals) IronPython.Hosting.PythonEngine.ExecuteToConsole(String text) IronPythonConsole.PythonCommandLine.DoOneInteractive() IronPythonConsole.PythonCommandLine.b__6(Boolean& continueInteractionArgument) IronPythonConsole.PythonCommandLine.TryInteractiveAction(InteractiveAction interactiveAction, Boolean& continueInteraction) ValueError: value too big >>> prime.nextPrime(nx) ** Going into an infinite loop; Interrupt with Ctrl+C *** IronMath.BigInteger.op_Multiply(BigInteger x, BigInteger y) IronMath.BigInteger.Square() IronMath.BigInteger.ModPow(Int32 power, BigInteger mod) IronPython.Runtime.Operations.LongOps.PowerMod(BigInteger x, Int32 y, BigInteger z) IronPython.Runtime.Operations.LongOps.PowerMod(BigInteger x, Int32 y, Object z) IronPython.Runtime.Operations.LongOps.PowerMod(BigInteger x, Object y, Object z) IronPython.Runtime.Operations.IntOps.PowerMod(Int32 x, Object y, Objectz) IronPython.Runtime.Operations.Ops.PowerMod(Object x, Object y, Object z) IronPython.Modules.Builtin.Pow(Object x, Object y, Object z) IronPython.Runtime.Calls.FastCallableAny.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) IronPython.Runtime.Calls.BuiltinFunction.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1, Object arg2) nzmath.prime.spsp$f1(Object n, Object base, Object s, Object t) C:\NZMATH-0.5.1\nzmath\prime.py:line 43 IronPython.Runtime.Calls.Function4.Call(ICallerContext context, Object arg0, Object arg1) IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1) nzmath.prime.small
Re: [IronPython] Bug of big integer manipulation
Thanks for the answer. I was able to take a log with -X:ExceptionDetail, but since Japanese, log file includes Japanse characters; I removed them by hand. I was not able to which numbers were involved. The log file is attached. Please note that there are two problems; one is "ValueError: value too big" problem which we do not encounter with CPython. The other is an infinite loop bug. Please also note that NZMATH is pure python, having simple module structure and we will be able to duplicate the problem if you download it. Best regards, 2006/8/10, Martin Maly <[EMAIL PROTECTED]>: By any chance, were you able to determine which operation caused the exception and which numbers were involved? What would help me find out what the problem is faster would be get a call stack (for that, could you please run your repro with -X:ExceptionDetail switch? Then ideally if you could find out what the big integer numbers were with which the operation failed, that would be ideal. Thanks! Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HEMMI, Shigeru Sent: Tuesday, August 08, 2006 4:31 PM To: Discussion of IronPython Subject: [IronPython] Bug of big integer manipulation Hello, NZMATH is a Python based number theory oriented calculation system developed by Tokyo Metropolitan University. The URL is http://tnt.math.metro-u.ac.jp/nzmath/. Using NZMATH, I encounterd a bug of big integer manipulation. IronPython C:\IronPython-2604>ipy IronPython 1.0.2411 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import sys >>> sys.path.append(r'C:\Python24\Lib') >>> sys.path.append(r'C:\Python24\Lib\site-packages') >>> from nzmath import prime >>> prime.nextPrime(256) 257 >>> nx = sys.maxint >>> prime.nextPrime(nx*nx) Traceback (most recent call last): File , line 0, in ##115 File C:\Python24\Lib\site-packages\nzmath\prime.py, line 158, in nextPrime File C:\Python24\Lib\site-packages\nzmath\prime.py, line 206, in primeq File C:\Python24\Lib\site-packages\nzmath\prime.py, line 188, in smallSpsp File C:\Python24\Lib\site-packages\nzmath\prime.py, line 41, in spsp ValueError: value too big >>> prime.nextPrime(nx) ## Seems going into infinite loop. CPython C:\IronPython-2604>python Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> from nzmath import prime >>> nx = sys.maxint >>> prime.nextPrime(nx*nx) 4611686014132420667L >>> prime.nextPrime(nx) 2147483659L >>> Regards, ___ 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 IpyBugOfBigIntegerManipulation.log Description: Binary data ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
