Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote: > On 10/17/07 Tony Djordjevski wrote: >>> You do need to write C code as the API is a C API. I didn't list in the >>> last mail because the C implementation of these functions is not a >>> difference between the C# impl and the C++ impl of the rest of the code. >>> The dllimport declarations I mentioned above would pinvoke to these C >>> functions. >> Those C functions you speak about will need to execute managed code. >> >> So, either way, what needs to be done is to allow "Reverse P/Invoke" or >> some form of DllExport. Assuming this project is successful, native >> C/C++ will have to, at some point, execute managed code. >> >> There are only two ways that I know of that you can accomplish this in .NET: >> 1. C++ Interop >> 2. Modifying a compiled assembly > > or 3, the easiest of all: using function pointers in the C code which > the runtimes will generate automatically when passing a delegate > to a p/invoked method. > Besides being trivial compared to both 1 and 2, it works on Mono and it > works on the MS CLR. > Happy hacking! > > lupus > You're right. I actually forgot about that one, hence my post. Best Regards, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote:
> On 10/17/07 Curt Hagenlocher wrote:
>> On 10/17/07, Paolo Molaro <[EMAIL PROTECTED]> wrote:
>>> The python API requires a couple dozen structure definitions plus a few
>>> dozen dllimport declarations. This can be about 200 lines of trivial
>>> to write declarative stuff.
>> I'm having trouble understanding what you mean by this. Let's say I've got
>> an extension method that looks like this:
>>
>> PyObject * ModifyColumns(PyObject * self, PyObject * args)
>> {
> [...]
>> In order to use this extension from IronPython, I need C implementations of
>> each of those API functions. The PySequence_ methods should to be able to
>> understand CLR arrays or any other IEnumerable-like object. I'm not sure
>> what PyTuple_New should return, but whatever it is will need to have
>> PyObject*-like semantics.
>>
>> How does DllImport fit into this picture? How can I avoid implementing all
>> these functions in C or C++?
>
> You do need to write C code as the API is a C API. I didn't list in the
> last mail because the C implementation of these functions is not a
> difference between the C# impl and the C++ impl of the rest of the code.
> The dllimport declarations I mentioned above would pinvoke to these C
> functions.
>
Those C functions you speak about will need to execute managed code.
So, either way, what needs to be done is to allow "Reverse P/Invoke" or
some form of DllExport. Assuming this project is successful, native
C/C++ will have to, at some point, execute managed code.
There are only two ways that I know of that you can accomplish this in .NET:
1. C++ Interop
2. Modifying a compiled assembly
Option 1 has the disadvantage of not working in Mono (for now), but I
think is a "cleaner" solution.
Option 2 requires a post build event and I have no idea how that will
affect Mono, as I don't use Mono or ever tried this approach. This
article briefly discusses the method:
http://www.codeproject.com/useritems/DllExport.asp
The Cecil project might help with this, though I'm not sure:
http://www.mono-project.com/Cecil
PostSharp might be able to do this as well (again, I've never used it):
http://www.postsharp.org/
Regards,
Tony
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython v2.0 Alpha 2 Released!
Hi Dino, Congrats on the new release! Can you give us an update on the status of the multiple engine debate and does this release change anything on that front? When Alpha 1 was released, we discussed swappable SystemStates as an alternative to multiple engine instances. Does this release include this functionality? Thanks, Tony Dino Viehland wrote: > Hello IronPython Community, > > We have just released IronPython 2.0 Alpha 2. This release is a snapshot of > the on-going progress with IronPython 2.0 and the DLR. > One of the most significant changes in this release is the removal of > Microsoft.Scripting.Vestigial. Previously this DLL was a combination of both > IronPython support code as well as portions of the DLR. With Alpha 2 > Microsoft.Scripting.dll contains all portions of the DLR and IronPython.dll > contains the IronPython implementation which builds upon the DLR. This should > help consumers of the DLR to better understand the public surface area. Being > early in the product cycle this surface area may still change significantly > but there are now bright lines between what DLR code is and what IronPython > code is. > > IronPython also continues to use the underlying concepts of the DLR more and > more. In the Alpha 1 release there were numerous locations where IronPython > would use DynamicSites but fallback to runtime lookups because the site > couldn't perform optimally. In this release we've continued to flush out > these corner cases and improve IronPython's support for generating proper > rules when using DynamicSites. We've also improved the shared infrastructure > the DLR provides for creating rules and moved IronPython to this shared > infrastructure. > > Significant changes in the DLR include the removal of > Microsoft.Scripting.Vestigial, continued refinement of the AST and dynamic > site support, and replacement of the old IDynamicObject with the new > IDynamicObject. IronPython has also been updated to use more of the DLR > concepts. > The DLR also continues to be expanded and improved. The DLR AST has been > improved with support for more static constructs such as simple exception > handling constructors and better variable support. The DLR AST factory > methods have also been moved to a static Ast class to enable easier > construction of ASTs. There have also been some additional convenience > methods added to various nodes to make construction even easier still. > Finally the DLR also has been improved to support an arbitrary number of > arguments inside a DynamicSite which helps to enable calling all functions in > an optimized manner. > > One of the most significant (although fairly small) improvements is the > introduction of the IDynamicObject interface under its proper name. In the > Alpha 1 release this interface was temporarily named IActionable because > IronPython had previously shipped with an IDynamicObject interface. In this > new release the old interface has been completely removed and the DLR now > provides the correct IDynamicObject interface. This interface lives at the > heart of the DLR so it's noteworthy that it's now found its final home. > > Note: Due to dependencies upon APIs that are not present in Silverlight 1.1 > Alpha (released at MIX) you won't be able to re-build this release for use > with Silverlight. As both products stabilize more we expect better > compatibility between releases. > > You can download IronPython v2.0 at: > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=5246 > > ___ > 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] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
Dino Viehland wrote: > Thanks for the info... Darn, it sounds like you actually want sys to be > isolated... > > We're going to do a review over the hosting APIs internally next week. That > should result in the last large set of changes. One thought that has > occurred to me is the ability to provide management of the current sys > instance. This is where most of the state is tracked. That would presumably > be something like allowing you to create a new system state and provide the > current system state at runtime. You could then switch system states before > running a new script code. In the multi-threaded case you could store the > system state in a thread local variable. Therefore rather than tracking a > set of engines you'd track a list of SystemState objects (or in DLR speak > they may be some opaque state object). It sounds very similar to what we are currently doing with the native implementation. We are swapping out PyThreadState pointers by means of PyEval_AcquireThread and PyEval_ReleaseThread (See the Python/C API Reference, if you're interested). There is one problem that we've encountered by doing this: that is when there is some external stimuli (for lack of a better word) on a particular script while the state is swapped out. Python code tries to get executed when it's not available and the system crashes. The two most common cases our customers have been wanting to do (and we really want to give them this capability) is to create GUI for their scripts and to do sockets. In the case of the GUI, if a user clicks a button and the script has been swapped out, then there's trouble. Same with sockets when you receive a transmission. Both of these cases work fine if there is exactly one script in the whole system, but as soon as you add another, it's no dice. I guess the question is how do you swap a state back in when someone else is initiating the switch? Now, it could just be that this won't be a problem with what you're proposing, but I'll need more information. > The one interesting thing here is how this plays w/ console output. In v2.0 > that's separate from SystemState so you'd also need to update those at the > same time. That's not a problem, as we're already doing this in the native implementation. > Any feedback on that proposal? > > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony > Djordjevski > Sent: Wednesday, May 02, 2007 9:59 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was > IronPython 2.0 Alpha 1 Released) > > Thanks for the reply Dino. And sorry, this is going to be a long post. > > I guess the best way to tell you what we need from IronPython is to tell > you how our product works today. I should also note that we're porting > the application from native C++ to .Net. We currently have python > support by way of CPython and the Boost Python library. > > Our product is an emulation/simulation application within the > manufacturing domain. Our customers are able to emulate their > manufacturing process by adding virtual machines (what we call > components) to a 3D world that represents their factory floor. Each > component can have various "behaviors", and we supply some common > behaviors which the customer can add to a component. For example, a > conveyor component would have behaviors that deal with conveyance, > sensors that detect parts moving along the conveyor, and signals used > for communication, among others. > > The scripts are important because they are a means for the customer to > create custom behaviors (you can almost think of them as plugins). > Using the above example of a conveyor, a part might move down the > conveyor, a sensor would detect that part and then fire a signal. That > signal could be "wired" up to a script behavior. The script in turn > might turn off the conveyor, or slow it down, or do throughput analysis, > or a number of other things. > > The customer might have a number of these same conveyors on the factory > floor all with the same script behavior(s). The scripts need to be > isolated insofar that when they do turn off the conveyor, as in the > example above, that they turn off the conveyor in the component they are > associated with. So I would have to say that the state of the script > "instance" needs to be separate from each other. > > The scripts don't run all the time. They run once during compilation, > as that's the behavior of CPython. So any statements at the main module > level get executed then. If the script has specific functions
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
Thanks for the reply Dino. And sorry, this is going to be a long post. I guess the best way to tell you what we need from IronPython is to tell you how our product works today. I should also note that we're porting the application from native C++ to .Net. We currently have python support by way of CPython and the Boost Python library. Our product is an emulation/simulation application within the manufacturing domain. Our customers are able to emulate their manufacturing process by adding virtual machines (what we call components) to a 3D world that represents their factory floor. Each component can have various "behaviors", and we supply some common behaviors which the customer can add to a component. For example, a conveyor component would have behaviors that deal with conveyance, sensors that detect parts moving along the conveyor, and signals used for communication, among others. The scripts are important because they are a means for the customer to create custom behaviors (you can almost think of them as plugins). Using the above example of a conveyor, a part might move down the conveyor, a sensor would detect that part and then fire a signal. That signal could be "wired" up to a script behavior. The script in turn might turn off the conveyor, or slow it down, or do throughput analysis, or a number of other things. The customer might have a number of these same conveyors on the factory floor all with the same script behavior(s). The scripts need to be isolated insofar that when they do turn off the conveyor, as in the example above, that they turn off the conveyor in the component they are associated with. So I would have to say that the state of the script "instance" needs to be separate from each other. The scripts don't run all the time. They run once during compilation, as that's the behavior of CPython. So any statements at the main module level get executed then. If the script has specific functions defined, we call those python functions when particular simulation events take place. To answer some of your specific questions: Q1. Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? A1. I would have to say yes, for the most part. Shallow copies of imported modules are probably OK, but we aren't far enough into the migration to give you a definitive answer. There is one case in our C++ implementation that this caused a problem and we were forced to call the module's init function for each interpreter behind the scenes. As far as everything in sys is concerned, maybe not but I can think of at least one situation that it must be isolated. Currently, we redirect sys.stdout and sys.stderr to a window in our application, but that doesn't stop a user from redefining those manually in one of their scripts. If they do, then it shouldn't affect any other script in the application. Other things, like sys.version, don't have to be isolated. Q2. Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). A2. No and in our case I don't think that would be desirable. The scripts themselves need to be able to interact with other objects within the simulation world. Q3. If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? A4. I'm fairly new to .Net, so I'm not sure. I'll have to read up on app domains, but my gut tells me that is not what we want here. I hope this sheds more light, Dino. I tried to be as clear as possible, but it was a bit difficult to keep this short(ish) and still convey our needs. Let me know if I can elaborate on any other questions you might have, or if anything I've wrote here is unclear. One thing to think about: eventually we want to make our simulation engine multi-threaded. Script functions will probably be getting executed in parallel at some point. Thanks, Tony Dino Viehland wrote: > I'm not actually the one working on the engine APIs so that's the reason I've > tended to be vague. I'll talk to the people doing it and let you know what I > hear. > > But the more info you can give us the better decision we'll be able to make. > For example what do you actually need to be isolated? Do you need multiple > system states so they get their own modules, console, etc... do you need > everything in sys isolated? Do you need to guarantee the isolation even if > .NET code is called (e.g. they could smuggled data via a static field). If > they do need some rather high level of isolation are app domains good enough? > Do you need to marshal a lot of data in/out? Or is the effort to spin up > and use app domains correctly? > > Ultimately understanding the scenarios where this is being used might end up > with us coming up with an even be
[IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
Hi Dino, You indicated that multiple engine support might be available in the coming changes with the hosting APIs. Is there any chance that we can get a definitive answer one way or another? And if so, will it be available for 2.0 final? Our product depends on IronPython being able to run multiple scripts in isolation from each other. At some point in the future, we'd also like to be able to run scripts in parallel. Now, I don't know if there is another mechanism planned (or currently available) that would allow us to do this, but I believe multiple engine instances would give us these capabilities. Thanks for the consideration, Tony Dino Viehland wrote: > Yeah, incase the release notes aren't obvious there's a bunch of things that > go with this: IronPython in the web browser (IE, FireFox, and Safari - yes, > there's Mac support as well) via Silverlight. There's an ASP.NET Futures > which has also launched (linked from our home page on CodePlex), not to > mention the DLR. > > Anyway, back to the hosting APIs :). They don't support multiple instances > now but we still have an additional round of changes to go through w/ the > hosting APIs. I'm not sure what will happen with that. I'm also not sure > that we actively prevent creating 2 instances but I know we've made some > spots singleton's that used to not be - therefore if you tried it you'd > likely run into issues. Additionally the entire hosting API surface is also > quite different. I have a version that wraps the v2.0 APIs and exposes a > v1.x-esque engine which I'll make available somewhere in a couple of days. > > > From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Michael Foord [EMAIL > PROTECTED] > Sent: Monday, April 30, 2007 4:58 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released > > Hello Dino, > > Wow - this seems like a big deal. :-) > > Does IronPython 2 still support hosting multiple IronPython engines ? > > Thanks > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] wierd import problem
Thanks Dino! That fixes it.
In case anybody is interested, I originally came across this problem
while trying to host IronPython. In order to get workaround #1 working
in a hosting situation, you'll need to do the following:
IronPython.Compiler.Options.ImportCompiledModule = false;
Thanks again,
Tony
Dino Viehland wrote:
> It's an alias to run IronPython 2.0 in my dev environment :( I don't think
> we've actually ported the pre-compiled module feature to the v2.0 branch so
> this just works there.
>
> Ok, so either this is a bug or a feature depending on how you look at it (we
> either be ignoring the DLL or our complaining loudly is the right thing,
> depending upon your perspective). Anyway, I've opened a new bug (#9807):
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9807
>
> There's two work arounds for this issue:
> #1) Run w/ -X:NotImportCompiled, this disables this feature which is
> raising this exception.
> #2) Use the assembly object directly instead of importing the
> namespace:
>
> import clr
> asm = clr.LoadAssemblyByName('Foo.bar')
> inst = asm.Foo.Bar.Bar()
>
> I've even made sure they work right on v1.1 this time :)
>
> Thanks for the bug report and sorry for messing up the repro. Hopefully one
> of those workarounds will work for you.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony
> Djordjevski
> Sent: Monday, April 23, 2007 2:43 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] wierd import problem
>
> Dino,
>
> What's ipyd? I noticed in your example that worked, you ran that
> instead of ipy.
>
> Here's the output I'm getting:
>
> C:\Temp\Foo\bin\Debug>dir
> Volume in drive C has no label.
> Volume Serial Number is 5454-DE81
>
> Directory of C:\Temp\Foo\bin\Debug
>
> 04/23/2007 02:55 PM .
> 04/23/2007 02:55 PM ..
> 04/23/2007 02:55 PM16,384 Foo.Bar.dll
> 04/23/2007 02:55 PM11,776 Foo.Bar.pdb
> 04/23/2007 02:55 PM16,384 Foo.exe
> 04/23/2007 02:55 PM11,776 Foo.pdb
> 09/23/2005 07:56 AM 5,632 Foo.vshost.exe
> 04/10/2007 10:17 AM71,016 ipy.exe
> 04/10/2007 10:17 AM62,824 ipyw.exe
> 04/10/2007 10:17 AM50,536 IronMath.dll
> 04/10/2007 10:17 AM 1,373,544 IronPython.dll
> 9 File(s) 1,619,872 bytes
> 2 Dir(s) 91,054,919,680 bytes free
>
> C:\Temp\Foo\bin\Debug>ipy
> IronPython 1.1 (1.1) on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference('Foo.Bar.dll')
> >>> import Foo.Bar
> Traceback (most recent call last):
>File , line 0, in ##14
>File , line 0, in __import__##7
> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
> try again after deleting it.
> >>> ^Z
>
> C:\Temp\Foo\bin\Debug>ipy
> IronPython 1.1 (1.1) on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference('Foo.Bar')
> >>> import Foo.Bar
> Traceback (most recent call last):
>File , line 0, in ##14
>File , line 0, in __import__##7
> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
> try again after deleting it.
> >>> ^Z
>
> C:\Temp\Foo\bin\Debug>ipy
> IronPython 1.1 (1.1) on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference('foo.bar')
> >>> import Foo.Bar
> Traceback (most recent call last):
>File , line 0, in ##14
>File , line 0, in __import__##7
> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
> try again after deleting it.
> >>> ^Z
>
> The last example was a "shot in the dark" attempt to see if case had
> anything to do with the AddReference. I didn't actually expect it to work.
>
> Dino Viehland wrote:
>> Oh, it seems to be the presence of the '.dll' in the filename (although I
>> still haven't looked too deeply to understand the exception). See below for
>> the 3 different variations I've tried. The .NET loader will append
>> .dll/.exe for you automatically.
>>
>> F:\repro\foo\Foo\bin\Debug>dir
>> Volume in drive F is New Volume
>> Volume Serial Number is F62E-82C1
>>
>> Directory of F:
Re: [IronPython] wierd import problem
Dino,
What's ipyd? I noticed in your example that worked, you ran that
instead of ipy.
Here's the output I'm getting:
C:\Temp\Foo\bin\Debug>dir
Volume in drive C has no label.
Volume Serial Number is 5454-DE81
Directory of C:\Temp\Foo\bin\Debug
04/23/2007 02:55 PM .
04/23/2007 02:55 PM ..
04/23/2007 02:55 PM16,384 Foo.Bar.dll
04/23/2007 02:55 PM11,776 Foo.Bar.pdb
04/23/2007 02:55 PM16,384 Foo.exe
04/23/2007 02:55 PM11,776 Foo.pdb
09/23/2005 07:56 AM 5,632 Foo.vshost.exe
04/10/2007 10:17 AM71,016 ipy.exe
04/10/2007 10:17 AM62,824 ipyw.exe
04/10/2007 10:17 AM50,536 IronMath.dll
04/10/2007 10:17 AM 1,373,544 IronPython.dll
9 File(s) 1,619,872 bytes
2 Dir(s) 91,054,919,680 bytes free
C:\Temp\Foo\bin\Debug>ipy
IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Foo.Bar.dll')
>>> import Foo.Bar
Traceback (most recent call last):
File , line 0, in ##14
File , line 0, in __import__##7
SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
try again after deleting it.
>>> ^Z
C:\Temp\Foo\bin\Debug>ipy
IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Foo.Bar')
>>> import Foo.Bar
Traceback (most recent call last):
File , line 0, in ##14
File , line 0, in __import__##7
SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
try again after deleting it.
>>> ^Z
C:\Temp\Foo\bin\Debug>ipy
IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('foo.bar')
>>> import Foo.Bar
Traceback (most recent call last):
File , line 0, in ##14
File , line 0, in __import__##7
SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
try again after deleting it.
>>> ^Z
The last example was a "shot in the dark" attempt to see if case had
anything to do with the AddReference. I didn't actually expect it to work.
Dino Viehland wrote:
> Oh, it seems to be the presence of the '.dll' in the filename (although I
> still haven't looked too deeply to understand the exception). See below for
> the 3 different variations I've tried. The .NET loader will append .dll/.exe
> for you automatically.
>
> F:\repro\foo\Foo\bin\Debug>dir
> Volume in drive F is New Volume
> Volume Serial Number is F62E-82C1
>
> Directory of F:\repro\foo\Foo\bin\Debug
>
> 04/23/2007 01:45 PM .
> 04/23/2007 01:45 PM ..
> 04/23/2007 01:42 PM 4,096 Foo.Bar.dll
> 04/23/2007 01:42 PM11,776 Foo.Bar.pdb
> 04/23/2007 01:42 PM 4,096 Foo.exe
> 04/23/2007 01:42 PM11,776 Foo.pdb
> 04/10/2007 10:17 AM71,016 ipy.exe
> 04/10/2007 10:17 AM62,824 ipyw.exe
> 04/10/2007 10:17 AM50,536 IronMath.dll
> 04/10/2007 10:17 AM 1,373,544 IronPython.dll
> 04/23/2007 01:45 PM tmp
>8 File(s) 1,589,664 bytes
>3 Dir(s) 35,566,551,040 bytes free
>
> F:\repro\foo\Foo\bin\Debug>.\ipy.exe
> IronPython 1.1 (1.1) on .NET 2.0.50727.1318
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import clr
>>>> clr.AddReferenceToFile('Foo.bar.dll')
>>>> import Foo.Bar
> Traceback (most recent call last):
> File , line 0, in ##14
> File , line 0, in __import__##7
> SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module;
> try again after deleting it.
>>>> ^Z
>
> F:\repro\foo\Foo\bin\Debug>.\ipy.exe
> IronPython 1.1 (1.1) on .NET 2.0.50727.1318
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import clr
>>>> clr.AddReference('Foo.bar.dll')
>>>> import Foo.Bar
> Traceback (most recent call last):
> File , line 0, in ##14
> File , line 0, in __import__##7
> SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module;
> try again after deleting it.
>>>> ^Z
>
> F:\repro\foo\Foo\bin\Debug>ipyd
> IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import clr
>>>> clr.AddReference('foo.bar')
>>>> import Foo.Bar
>>>> dir(Foo.Bar)
> ['Bar']
>
Re: [IronPython] wierd import problem
Hi Dino,
Sorry, I should have mentioned in my original post that I've already
tried to get it to work with all the AddReference* methods.
AddReferenceToFile was just the last example that I tried at the time I
sent the original post.
Currently I'm still getting the same error. I've even tried variations
on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference
always seems to work, it's just that the import has problems.
I've just tried the example on another computer, and it's showing the
same issue.
Thanks for the help,
Tony
Dino Viehland wrote:
> I haven't had a chance to track down what the underlying problem here is (and
> suspect this is a bug), but is there a reason you can't do:
>
>>>> import clr
>>>> clr.AddReference('Foo.bar.dll')
>>>> import Foo.Bar
>
> This seems to work. The only reason to use AddReferenceToFile is really if
> you are dealing with assemblies that live outside of your app domain base.
> In that case AddReferenceToFile will attempt to use sys.path to search for
> referenced assemblies when the CLR loader attempts to load them.
>
> But if you're using this DLL from within your app domain base then doing
> AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which
> will succeed and also get the dependencies using the standard .NET way.
>
> Let me know if this is a reasonable workaround for you and I'll continue to
> look into the underlying issue here.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony
> Djordjevski
> Sent: Monday, April 23, 2007 12:36 PM
> To: users@lists.ironpython.com
> Subject: [IronPython] wierd import problem
>
> Hi everyone,
>
> I'm seeing a bit of weirdness when trying to import a dll with a nested
> namespace. Actually, I'm not sure if it's a filename issue or a namespace
> issue, as the filename of the assembly is named after the namespace.
>
> OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a
> simple Visual Studio project to recreate the situation)
>
> I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe
>
> Here's the steps to reproduce:
>
> >>> import clr
> >>> clr.AddReferenceToFile('Foo.Bar.dll')
> >>> import Foo.Bar
> Traceback (most recent call last):
>File , line 0, in ##14
>File , line 0, in __import__##7
> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try
> again after deleting it.
> >>> for ref in clr.References:
> ... print ref
> ...
> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
> System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
> Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>>
>
> As the output shows, Foo.Bar has been referenced. So what am I doing wrong
> that I can't import?
>
> BTW, I'm using IP v1.1 (in case you're wondering).
>
> Thanks,
> Tony
>
> ___
> 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
