Presumably CPython is linking against msvcrt and is using the C abstraction
rather than calling the Win32 APIs which return handles directly.
As Curt said the biggest problem for us is that .NET does not expose C file
descriptors. Therefore we could fix this by P/Invoking out to msvcrt. For
u
You should call PythonOps.IsSubClass and pass in the PythonType and the
interface you want to compare it with. The interface can be either a .NET type
object or another Python type object (or a tuple, etc...)
The not raising on missing functions is a feature :) You could build a
meta-class wh
Can you open a feature request on CodePlex? It's certainly an interesting idea
to ponder and I'm leaning towards it but there's lots of details to be gotten
right.
Do you know if this needs to work w/ sockets as well? (There's also the
question of can we make it work with sockets? :))
There
.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, December 15, 2008 12:53 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython and file descriptors
2008/12/15 Dino Viehland mailto:di...@microsoft.com>>
Presumably CPython is linking agai
I think this behavior is currently by design because we're using sys.meta_path
which does take precedence over the built-in modules. We could switch to using
sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable
(which would also give control over when pre-compiled modul
on part with CPython. But this is not only a
potentially breaking change, it also would require modification to the standard
library for at least the "socket" module.
On Mon, Dec 15, 2008 at 3:04 PM, Michael Foord
mailto:fuzzy...@voidspace.org.uk>> wrote:
Dino Viehland wrote:
I
ehalf Of Michael Foord
Sent: Monday, December 15, 2008 3:04 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiled dlls and builtin modules
Dino Viehland wrote:
>
> I think this behavior is currently by design because we're using
> sys.meta_path which does take precedenc
I've actually looked at this not too long ago and I think your proposal of
calling the Invariant functions is the correct solution. I was looking at a
few things: This bug http://bugs.python.org/issue1528802, the 3.0 decimal.py
module, and also just using Turkish I at the command prompt. If y
My guess would be that we're pushing the PythonContext._callSplatSite outside
of the sweet spot in DLR site caches.
You could check this by putting a breakpoint in PythonContext.Call(object,
params object[]). Then look and see if _callSplatSite._rules is an instance of
EmptyRuleSet with _suppo
I'm guessing the comparison to CPython here is a comparison to code that has
been exec'd or eval'd. You can pass a PythonCompilerOptions to
scriptSource.Compile with ModuleOptions.ExecOrEvalCode and you should then get
the 1.x/CPython behavior.
From: users-boun...@lists.ironpython.com
[mailto
olves the problem in our code.
> >
> > As a short term solution we have removed all the properties from
> > decorated functions. This fixed one performance test. We moved to
> > other performance tests and we still see that some functions are
> > slower when executed from d
mance tests and we still see that some functions are
> slower when executed from dlls, so the same slow down might be
> triggered by sth else.
>
> On Wed, Dec 17, 2008 at 3:21 AM, Dino Viehland
> wrote:
> > My guess would be that we're pushing the PythonContext._callSplatSite
>
perties from
> decorated functions. This fixed one performance test. We moved to
> other performance tests and we still see that some functions are
> slower when executed from dlls, so the same slow down might be
> triggered by sth else.
>
> On Wed, Dec 17, 2008 at 3:21 AM, Dino Vieh
This is just a test... there were some issues with the mailing list today, just
verifying that it should be back now.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
nally would be
pro-backporting.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, December 15, 2008 11:13 PM
To: glenn.k.jones+...@gmail.com; Discussion of IronPython
Subject: Re: [IronPython] Issue about string.uppe
Are there other exceptions being thrown, potentially somewhere on the stack
below game\models\__init__.py on line 144? Maybe we're calling a built-in
function somewhere that's calling back into your code and is doing something
funky with the exception tracking. Can you run this under VS and ge
It is certainly more like 50% on trivial functions than 10%. Given that I have
this mostly written I think we can probably get it into 2.1.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday,
This would appear to be a bad default value for compiling. You can explicitly
disable compiling the code as optimized and it will be fully collectible:
var runtime = Python.CreateRuntime();
var engine = runtime.GetEngine("py");
var sum = 0.0;
PythonCompilerOptions pco = (PythonCompilerOptions)en
n it's out of scope? Or do I have to explicitly set
GC collection after usage?
Dody G.
On Fri, Jan 2, 2009 at 7:59 PM, Dino Viehland
mailto:di...@microsoft.com>> wrote:
This would appear to be a bad default value for compiling. You can explicitly
disable compiling the code as opt
Strangely I don't see one - this is frequently asked for so I'm a little
surprised :)
I have a plan on how to enable this (and some other .NET scenarios) in the next
major release. My current thinking is to support this via meta-classes and
providing a new method on type which lets you specify
I think we are thrashing the hash code call site in
CommonDictionaryStorage.HashSite._HashSite. Alternately it could be the equals
call site in PythonContext._equalRetBoolSite.Similar to the property issue
you can look at the call site object and see if it's going to the fixed
read-only Em
Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, January 06, 2009 3:07 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Get a string from JavaScript to IronPython
Dino Viehland wrote:
> Strange
You should be able to just copy and paste throwing error sink into your own
version, it's pretty simple:
internal class ThrowingErrorSink : ErrorSink {
public static new readonly ThrowingErrorSink/*!*/ Default = new
ThrowingErrorSink();
private ThrowingErrorSink() {
}
d[i] = 0
i in d
del d[i]
import time
start = time.clock()
data = data[-5:]
x = {}
for i in xrange(10):
for val in data:
x[val] = 0
val in x
del x[val]
end = time.clock()
print end - start
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lis
sted (in the wild) code, but we have pretty
> comprehensive tests. 2.1 is also a bit of a Python 2.5 / 2.6 hybrid at
> the moment I guess - are there any potential gotchas?
>
> Michael
>
> Dino Viehland wrote:
> >
> > Ok, I've looked at this more closely now and I
It'll return "posix" if the .NET implementation reports
System.Environment.OSVersion.Platform as Unix.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Thursday, January 08, 2009 4:13 PM
> To: Di
You want to look at IronPython Studio: http://www.codeplex.com/IronPythonStudio
Note it's really pre-beta quality so you may or may not find the experience
acceptable.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Vadim Khaskel
Sent: Sunday, Ja
This is a bug - we're not adding references to mscorlib/System.dll when we run
your app. You can just:
import clr
clr.AddReference('mscorlib')
clr.AddReference('System')
to your program. Alternately you could modify pyc.py to send these two strings
in the references array to InitializeModule
Good places to look would be:
ExceptionHelpers.UpdateStackTrace is where the frame should be
remembered
PythonOps.CreateTraceBack should be where we actually pull the current
set of frames for exceptions and build up the stack trace
ScriptingRuntimeHelpers.GetDynamicStackF
ly suspicious of the
> big block of code in GetDyanmicStackFrames that seems to be for
> filtering bad frames out, which is ifdefed out for silverlight. Do you
> remember why that part isn't used for silverlight? I'll keep digging
> and see if I find anything more concrete.
>
> Tha
An alternate plan would be to run your script in another app domain. Then you
can just unload the app domain and all shared state will be cleared. The
hosting APIs make this pretty easy to do as well.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Beha
You need to do:
eng.ExecuteFile('myfile.py', scope);
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Renaud Durand
Sent: Wednesday, January 21, 2009 7:45 AM
To: d...@nomadlife.org; Discussion of IronPython
Subject: Re: [IronPython] Calling a Pyth
on.com] On Behalf Of Renaud Durand
Sent: Wednesday, January 21, 2009 8:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Calling a Python function (compiled into an assembly)
from C# using delegates.
That is the point. I don't want to do that from a file but from an Assembly
(dll)
This is related to 470 but is slightly different. But in both cases the CLR is
lying to us and telling us your object does implement the interface but it
really doesn't (or I'm assuming that's the case, maybe whatever you're doing
Activator.CreateInstance does implement the interface). But now
do anything with Linq or expressions so I'm
not sure where it's coming from.
Marc
On Wed, Jan 21, 2009 at 5:27 PM, Dino Viehland wrote:
> This is related to 470 but is slightly different. But in both cases the CLR
> is lying to us and telling us your object does implement the i
un(Scope scope)
> at
> IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1. ion>b__0()
> SystemError: Type 'Microsoft.Linq.Expressions.ParameterExpression' in
> Assembly 'Microsoft.Scripting.Core, Version=0.9.0.0, Culture=neutral,
> PublicKeyToken=31b
, argValue);
}
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Wednesday, January 21, 2009 6:21 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Remoting broken in
Precompilation (see the pyc.py sample) + ngen is the best story here right now.
The time is mostly spent compiling IL to native code. We're also working on
fixing that on our side (which hopefully will make it into 2.6, but it's
available in the source drops today under the -X:AdaptiveCompilat
You're right that it worked in 1.0 - but of course in 1.0 we would also end up
with an arbitrary ordering between engines. For example you could have:
Engine 1:
Sys.path = C:\
Contains "Foo.dll"
Engine 2:
Sys.Path = D:\
Contains "Foo.dll"
Which F
chael Foord
Sent: Friday, January 30, 2009 3:30 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
Dino Viehland wrote:
> You're right that it worked in 1.0 - but of course in 1.0 we would also end
> up with an arbitrary ord
You can always provide your own stream which is aware of what the current
output window is. It could store this in a thread static or just some variable
that you update whenever the active window changes. You can set that via
ScriptRuntime.IO.OutputStream. You could conceptually do the exact
Sent: Friday, January 30, 2009 6:41 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Redirecting stdout/stderr, but with context
Dino Viehland wrote:
> You can always provide your own stream which is aware of what the current
> output window is. It could store this in a thread sta
What do you mean by 'existing'? Do you want the class definitions which the
current statement is nested in? Do you want to get to an arbitrary class
definition somewhere in the AST?
Currently we don't maintain any of this but there's no reason you couldn't
modify PythonAst.TransformToAst so t
es (alpha-level) support for numpy using
our Ironclad project.
We're releasing the beta tomorrow: this has a few performance
problems (which are being addressed - many thanks to Dino Viehland
for helping with this!) but is otherwise functionally complete.
If you're interested in
ic, just about being "less" platform specific...
>
> I believe the official term is:
> "write once, debug everywhere"...
>
> Shechter.
>
> On 04/02/2009, at 23:43, Slide wrote:
>
>> I think that is a great plan. Having no P/Invokes makes it much m
ence which is a nasty hack and
we'd rather not do it :)
Regards,
Orestis Markou
Resolver Systems Ltd.
Dino Viehland wrote:
> Yep, and I'm happy to move back to the old behavior - being consistent w/
> ourselves and broken seems better than being inconsistent w/ ourselves and
> br
#x27;t have any (informal) documentation for the
parser/compiler?
Eyvind.
-Opprinnelig melding-
Fra: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] På vegne av Dino Viehland
Sendt: 4. februar 2009 18:04
Til: Discussion of IronPython
Emne: Re: [IronPython] Ge
There's no existing functionality to do this but we could add __repr__
overloads onto the built-in types. They would presumably return something like:
System.UInt32(1)
or:
UInt32(1)
Could you open a bug?
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun.
And the correct change to the source code would be adding __repr__ methods to
the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct
formatting. Presumably by updating the scripts that generate these types.
OTOH there's nothing particularly unsafe about your changes othe
ers-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, February 07, 2009 6:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] repr() results with uint, etc.
Dino Viehland wrote:
> And the correct change to the source co
Or if your program has no UI components you can start with the -X:MTA option
and the warning won't get issued.
Unfortunately the 2nd you hit a different warning it's likely you'll have the
same problem. So the underlying problem looks like we're somehow picking up a
different linecache.py or t
I would suggest enabling exception detail and getting the stack trace from
there if you can. The problem is probably a .NET list or a dict somewhere that
we're both updating an iterating over at the same time. But it's hard to know
what list/dict that is without the stack trace. But a full st
If I setup this as you describe from the command line it just works:
x\
subdir\
__init__.py
mymodule.py:
import clr
clr.AddReference('System')
from System.Diagnostics import Process
sting your time.
pj
On Mon, Feb 9, 2009 at 7:49 PM, Dino Viehland wrote:
> If I setup this as you describe from the command line it just works:
>
> x\
>subdir\
>__init__.py
>mymodule.py:
>import clr
>
Awesome, thanks for tracking this down. This looks trivial to fix - we're just
missing a lock statement. I've added the lock to my next change that will go
in (probably today).
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On B
It sounds like you're hitting a bug in the codedom round tripping support.
IronPython Studio is really more of a sample and leaves much to be desired so
it's likely you'll hit many more. Michael Foord who has done tons of winforms
development I believe recommends designing it in C# and then yo
Here are the original PyBench results from when we switched to the new
dictionary implementation back in February of last year:
Test minimum run-timeaverage run-time
thisother diffthisother diff
It's an in-place upgrade so you don't need to re-build hosts that were built
against the previous versions of IronPython - they'll just continue to work.
If we changed the .NET assembly version then you'd either have to apply policy
or rebuild. The assembly file version is updated and that's h
y files and being explicit about versions is a .NET way of life.
I think maybe you guys have had your heads in the dynamic sand for too long :)
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
ith the guidance Microsoft provides in general to developers.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPy
This is definitely a bug (and quite an annoying one at that). I've opened
CodePlex bug #21199 to track the issue
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21199).
Thanks for the report!
I'll try and get this fixed in 2.6 fairly soon and depending on what the fix
looks
Just to be clear - we could probably redistrubte a modified standard library if
we wanted to, the bar for that is probably not too high compared to
contributions. But we've made a conscious decision to not do this - we'd like
to get the point where we can give our changes back to the CPython co
module
Dino Viehland wrote:
> Just to be clear - we could probably redistrubte a modified standard library
> if we wanted to, the bar for that is probably not too high compared to
> contributions. But we've made a conscious decision to not do this - we'd
> like to get the p
From: users-bounces at lists.ironpython.com [mailto:users-bounces at
lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1
... Minor non-breaking releases are in-place upgrades ... B
There was this recent thread which might help:
http://lists.ironpython.com/pipermail/users-ironpython.com/2009-January/009606.html
You could alternately replace sys.displayhook and do a similar thing (we'll
flow a CodeContext into there if you define the function in C#, you can get the
Scope, a
Generally what you'd do is:
import clr
clr.AddReference('yourdll')
from MyNamespace import NotificationTypeEnum
I have no idea where the 'Imports are disabled' exception would come from
though. If you could include the actual text of the exception that might be
helpful. Also running w/ the -X
l Foord
> Sent: Thursday, February 19, 2009 9:55 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] how to use an enum from a hosted script
>
> Dino Viehland wrote:
> > Generally what you'd do is:
> >
> > import clr
> > clr.AddReference('yourd
Depending on what you're doing you might be better off using Func
instead of CallTarget0. CallTarget0 is more of a Python implementation detail
and could change w/ major IronPython versions - or even be replaced w/
Func. it's primary purpose is to be the delegate for calling a
zero-arg Python
Thanks for reporting this - it looks like we just need to set the __doc__ in
the dict to None.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Christian Muirhead
> Sent: Tuesday, February 24, 2009 7:51 AM
> To: us
Can you run w/ the -X:ExceptionDetail command line option the for the import
Crypt / from Crypto import * and report back the stack trace you get?
I'm not sure that I'll be of much use but if it's somewhere in IronPython
instead of IronClad it might be an IronPython bug.
> -Original Message
Just 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
down from there. If that's not sufficient maybe we can iterate and
figure out what's going on.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
> Sent: Wednesday, February
that instance.
CallTarget solved my problem... Do you know any other methodology that works
better then CallTarget?
Thank you,
António Piteira
2009/2/22 Dino Viehland mailto:di...@microsoft.com>>
Depending on what you're doing you might be better off using Func
instead of CallTarget0.
You can create the DataSeries object for them and include it in each call? Or
can you do something like:
def Init():
return DataSeries()
and only call their Init function once?
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of R.
on.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
> Sent: Thursday, February 26, 2009 12:07 AM
> To: Dino Viehland
> Cc: Discussion of IronPython
> Subject: Re: [IronPython] Please vote up this DLR memory leak bug
>
> Microsoft.Scripting2.Cor
I can't run it right now but if these are happening on the finalizer thread
then this has most likely been fixed in the 2.6 branch already. The issue is
that when a generator is not run to exhaustion we need to call close() on it
which causes an exception to be thrown. But we can avoid the exc
This one is technically by design. The python code which calls __import__/does
import is the one that gets tainted with the ability to see clr attributes. We
have discussed changing the design so that "import clr" is recognized at
compile time and works like from __future__ ... instead of bein
This is the correct behavior. We expose protected members as normal members
that throw when the instance isn't a subclass defined in Python. But they need
to exist on the base class so that you can do things like super calls to them.
> -Original Message-
> From: users-boun...@lists.iro
om [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Saturday, March 07, 2009 11:51 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Patching __import__ can break .NET attribute
> access
>
> Dino Viehland wrote:
> > This one is te
ere a way to check if it is a protected member or not?
>
> On Mar 7, 7:49 pm, Dino Viehland wrote:
> > This is the correct behavior. We expose protected members as normal
> members that throw when the instance isn't a subclass defined in
> Python. But they need to exis
The fact that we allow setting to the dictionary when we shouldn't be much to
worry about - it is just odd. In either case we still have a .NET type defined
something like:
class NewType : YourBaseTypeHere {
public PythonDictionary __dict__;
public object[] __slots__;
..
This is fixed in 2.6 and we can backport the fix to 2.0. Could you open a bug
on CodePlex? If you want to add the fix locally you just need to add the lock
statement below to NewTypeMaker.StoreOverriddenMethods:
lock(PythonTypeOps._functions) {
foreach (BuiltinFunction bf i
The resolution of that bug was that we now expose explicitly implemented
interfaces automatically if there are no naming conflicts. But with COM it's
usually a different story - the members should always just be there. Do the
interop libraries use explicit interface implementation (if they did
Does this make it work?
class x(unicode):
def __init__(self, val): pass
def __new__(cls, val):
return unicode.__new__(cls, unicode(val))
x(1)
I've voted for the bug and raised the priority to medium. I've left it
proposed until we triage it as a team (we triage bugs every
It works on CPython 2.6 at least. You should only have to override __new__ if
you wanted to support different arguments than str/unicode.__new__ supports.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael F
The method you're trying to call is generic so you need to index into it to
provide the generic type:
mycalsvc.Insert[type(myentry)](myposturi, myentry)
We're considering adding inference for these type parameters in the future.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@l
The documentation for using the hosting APIs is available here:
http://dlr.codeplex.com/Wiki/View.aspx?title=Docs%20and%20specs&referringTitle=Home
as "dlr-hosting-spec.doc"
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On
Do you have IronPython.Modules.dll next to IronPython.dll?
IronPython.Modules.dll contains the implementation of thread.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jonatan Nilsson
> Sent: Wednesday, March 18
Also make sure you have IronPython.Modules.dll next to IronPython.dll (if
you're hosting IronPython instead of just running from the command line).
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> S
onPython] CP Issue #21659: Subclassing unicode
>
> On Mon, Mar 16, 2009 at 7:03 PM, Dino Viehland
> wrote:
> > Does this make it work?
> >
> > class x(unicode):
> > def __init__(self, val): pass
> > def __new__(cls, val):
> > return unicode
It's actually a CLR bug - we can't call this method from a dynamic method. We
could probably add a workaround and force it to always be called via reflection.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Friday, March 2
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.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf
Thanks for trying this!
If this is the only issue you might try going back a week or two in the
IronPython history. BuiltinFunction.Generated.cs is new code that was just
added. Alternately you could probably delete BuiltinFunction.Generated.cs and
just update BuiltinFunction.cs to remove it'
antely
> 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
ethod 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 y
Why do you need to cast to the base class? All of the members you need should
already be there.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Carolyn Johnston
(MSNAR)
Sent: Thursday, March 26, 2009 3:47 PM
To: Users@lists.ironpython.com
Subje
Yeah there is apparently an issue here, Resolver reported it to me the other
day off-line. We've been changing our code gen rather significantly and it
looks like our existing test coverage isn't hitting whatever the issue is here.
I'll probably look at it tomorrow.
From: users-boun...@lists.
You can do:
import clr
from System.IO import File
clr.AddReference(Assembly.Load(File.ReadAllBytes(assemblyName)))
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Samuel Tjokrosoesilo
Sent: Thursday, April 02, 2009 10:43 AM
To: Discussion of Iron
For the read case what happens if you explicitly pass FileShare.None instead of
FileShare.Read? The reason I ask is the default for FileShare is
FileShare.None unless FileAccess == FileAccess.Read.
We should just be picking the ctor w/o parameters here so my guess is that the
default values ar
What DLLs you want to be loaded? The reason I ask is that .NET assembly
loading doesn't really work on the basis of the current working directory -
instead it looks at the app base which by default is where your EXE is located.
We do modify sys.path so that IronPython can load things outside o
601 - 700 of 2031 matches
Mail list logo
