>From the stack trace this looks like it's Gtk# not interacting well
w/ dynamic defined subclasses on .NET.
My guess here is it's because IronPython defines a subclass of Gtk.Window
which lives in an AssemblyBuilder instance. This is an in-memory only
assembly and therefore .NET throws NotSupport
#1's definitely our bug. We're caching the lookup of __init__ from
Real and invoking that instead of doing the lookup each time. It
should be easy enough to fix. I've opened a bug (23555 -
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23555)
#2 I'd guess could be either that for
Could this be issue 2?
class Real(object):
def __new__(cls, *args, **kwargs):
print 'real new'
return object.__new__(Stub)
#def __del__(self): pass # uncomment me and this works as expected
class Stub(Real):
def __del__(self):
print "I've been finalized"
f
sage-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of William Reade
> Sent: Tuesday, July 21, 2009 9:20 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] object lifecycle issues
>
> Dino Viehland wrote:
> > #2 I'd
; *before* I post. At least we rediscovered the __del__ bug ;-).
>
> Incidentally, congratulations on 2.0.2!
>
> Dino Viehland wrote:
> > The first 2 things that occur to me is that either there's an
> exception
> > happening when we run WeakRefTracker's fin
This looks like it's due to a bug fix and is correct behavior - we used to
allow None + "abc" but we've fixed the issue and it now throws an exception
as expected.
Note CallTarget0 is no longer used by IronPython at all. We keep it around
though for backwards compatibility because people seem to
The core feature (__clrtype__ on type which can be used w/ meta-classes) which
enables them is present - but at this point it's all about making hard things
possible, not making them easy. The interesting parts still need to be built
still - but they're all Python code. Harry has some samples
You can just do:
x.FindAll(lambda inst:True)
or:
def MyPredicate(obj):
return True
x.FindAll(MyPredicate)
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Count László de Almásy
> Sent: Friday, July 24,
gt; FindAll(Predicate[Primitive])
>
> On Fri, Jul 24, 2009 at 10:15 AM, Dino Viehland
> wrote:
> > You can just do:
> >
> > x.FindAll(lambda inst:True)
> >
> > or:
> >
> > def MyPredicate(obj):
> >return True
> >
> >
I'll take a look and see what we can do. I think we've largely been ignoring
it because we don't directly own our own COM support (it comes from the DLR)
but maybe there's something we can do here.
On the tests we do generally include only passing tests. Sometimes we will add
failing tests to
-X:FullFrames promotes all local variables into the heap. So you can
always crawl the stack and look/change them for all methods.
-X:Frames only creates the frame objects and if something happens to
make us promote local variables (e.g. a closure, or a call to locals(),
exec, eval, dir(), vars())
YMMV on Mono - their 64-bit could have different performance
characteristics than our 64-bit JIT. On Windows it's a big win
because the 32-bit JIT is much, much faster than the 64-bit JIT.
Also does Mono have something like ngen? If so you should
definitely use it and you'll get much improved st
ObjectOperations.GetCallSignatures:
import clr
clr.AddReference('IronPython')
from IronPython.Hosting import Python
x = Python.CreateEngine()
def f(a, b, c): pass
x.Operations.GetCallSignatures(f)
prints:
Array[str](('f(a, b, c)'))
> -Original Message-
> From: users-boun...@lists.ironp
rgument names from hosting
>
> Thanks, Dino!
>
> It'd be nice if I didn't have to parse the signature, but that'll do
> for now.
>
> - Jeff
>
> On Fri, Jul 24, 2009 at 6:04 PM, Dino Viehland
> wrote:
> > ObjectOperations.GetCallSigna
We could patch our site.py and if worse comes to worse we may just do
that. But we've never re-distributed a modified version of the std
lib and we're not really wanting to start doing that. Rather we're
trying to work through things on our side to make the changes and
submit them back to the std
Michael wrote:
> An undefined name is an undefined name. Sympy must be doing some magic
> somewhere to inject the name into the namespace.
If I had to guess that magic could be something involving imports.
There's another import bug Harry wants me to look at before 2.6 is done
so I'll try and see
Michael wrote:
> Well I can submit a patch to site.py in Python 2.6 myself - although it
> probably won't be in a *released* version of Python by the time you RC.
> Is that helpful or not?
Yep, that'd be very helpful. I have a check-in ready to go Monday which
integrates SVN as of Tuesday or Wedn
on 2.6
>
> Michael Foord wrote:
> > Dino Viehland wrote:
> >> Michael wrote:
> >>
> >>> Well I can submit a patch to site.py in Python 2.6 myself -
> although it
> >>> probably won't be in a *released* version of Python by the time you
>
This is what we've tested so far :)
>>> import pdb
>>> def f():
... print 'hi'
... print 'goodbye'
...
>>> pdb.runcall(f)
> (2)f()
(Pdb) s
hi
> (3)f()
(Pdb) s
goodbye
--Return--
> (3)f()->None
(Pdb) s
>>> pdb.runcall(f)
> (2)f()
(Pdb) ?
Unfortunately there don't seem to be pdb tests so it
{
> IntPtr typePtr = CPyMarshal.ReadPtrField(ptr,
> typeof(PyObject), "ob_type");
> PythonType type_ = (PythonType)this.Retrieve(typePtr);
>
> object[] args = new object[]{};
> if (Builtin.issubclass(type_, TypeCache.Int32))
> {
>
If we just aliased LoadLibrary to dlopen will that work?
My hope was that we could basically rely upon Mono's P/Invoke mapping
to handle running ctypes on Linux. But maybe LoadLibrary/dlopen have
slightly different sigs and we need to handle that one specially.
> -Original Message-
> Fro
t;
> int dlclose(void *handle);
>
> Not quite the same as LoadLibrary.
>
> On Mon, Jul 27, 2009 at 3:13 PM, Dino Viehland
> wrote:
> > If we just aliased LoadLibrary to dlopen will that work?
> >
> > My hope was that we could basically rely upon Mono's P/In
Jeffrey wrote:
> 1. Performance
The bulk of this problem comes from basic.py line 804 where a closure
function is called w/ keyword argument. Passing the argument as a
positional argument causes us to be 6-7x slower instead of 50x. This
is probably a small perf gain on CPython as well so it's pro
Ok, I've finally got SQL server setup in a reasonable state where I can try and
repro this. This is what I'm trying to do. I have a database called
"mydatabase" which contains a table "Table_1" which contains 1 column of type
binary(4). I then attempt to do:
import System
conn =
System.Acti
Any thoughts on this? I can trivial add a DllImport to dlopen but
I need to know where it's declared :)
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Monday, July 27,
IronPython doesn't actually support INotifyPropertyChanged - it only
supports custom type descriptor so that WPF can get at the values
but it doesn't get the change notifications.
You could make an instance of ExpandoObject which does support it:
import clr
clr.AddReference('Microsoft.Scripting.C
*Mads
> Weitling
> *Sent:* Wednesday, August 05, 2009 12:54 AM
> *To:* users@lists.ironpython.com
> *Subject:* [IronPython] -X:EnableProfiler and DLR hosting API (2.6b2)
>
> Hi all and many thanks to Dino Viehland for answering my previous
> question re: sys.builtin_m
] -X:EnableProfiler and DLR hosting API (2.6b2)
Dino Viehland wrote:
> All the options should be the same as the command line options. So
> they're documented via ipy.exe /? :)
>
C:\compile>"c:\Program Files\IronPython 2.6\ipy.exe" /?
File /? does not exist.
> ---
The only way I can think of doing this today would be to use our Parser
And PythonWalker classes to parse the func def and then walk it and look
for NameExpressions.
You'd also need to look for GlobalStatement's, AssignmentStatement,
and AugmentedAssignmentStatement to know if it was a global or n
I believe this is the same as bug #18637
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=18637
This has been fixed in 2.6 already but thanks for reporting it.
Unfortunately we don't current accept contributions back to
IronPython.
> -Original Message-
> From: users-boun...@
Is this what you're trying to accomplish?
from System.Reflection import *
from System.Reflection.Emit import *
import System
import clr
clr.AddReference('System.Core')
dm = DynamicMethod("test", clr.GetClrType(System.Array[str]),
System.Type.EmptyTypes)
ilgen = dm.GetILGenerator()
ilgen.Emit(OpC
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of KATO Kanryu
> Sent: Friday, August 07, 2009 6:43 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] UTF-8 script every 1024 bytes are broken
>
> 2009/8/8 Dino Viehland wrote:
>
ation = adodbapi.adUseClient
then the program will run, but the rowcount will return as -1, rather than 6,
because the cursor is not actually changed to a local cursor.
So, to make a long story short: some change in IPy 2.6 has broken a needed (if
ugly looking) feature in adodbapi.
I will file a bug in
FYI the fix is checked in and available on CodePlex as of last Friday.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Harry Pierson
> Sent: Monday, August 10, 2009 4:57 PM
> To: Discussion of IronPython
> Subject:
y, August 10, 2009 5:03 PM
> To: Discussion of IronPython
> Cc: Discussion of IronPython
> Subject: Re: [IronPython] FlowDocument XAML syntax highlighting and
> restructured text
>
> Any idea if docutils works?
>
> Michael
>
>
> --
> http://www.ironpythoninaction
Just out of curiosity - how would you feel if we enabled the behavior
but issued a warning when it occurred? In v1.0 when we made this
decision we had no warning support and it could serve as a mitigating
factor in enabling it. But it could also be too noisy.
It's funny, I just got had to fix a
t allowed me to work around
> the current situaiton. a warning seems fine to me. even better, an
> explicit way for us to enable the behavior without a warning.
>
> On Mon, Aug 10, 2009 at 6:27 PM, Dino Viehland
> wrote:
> > Just out of curiosity - how would you feel if we enabl
KATO Kanryu wrote:
> Yes, many people are looking forward to the release of 2.6,
> but it seems that the development gets behind a bit the plan.
> I think that the 2.0 will release 1 or 2 times more.
I actually believe we've been tracking pretty close to the posted plan:
http://ironpython.codeple
Michael wrote:
> If I use the unicodedata module from FePy then it *seems* to work.
> Although I do see a warning that I don't see under CPython:
>
> :1: DeprecationWarning: object.__new__() takes no parameters
>
> Not dug in to see where it comes from.
It's a new warning in 2.6 - it could be that
Michael wrote:
> Nope, no class definitions - it just uses .NET functionality. It's a
> very short bit of code really - 77 lines of which 30 lines are a
> dictionary defining a category mapping.
I looked at this closer looking at all combinations of __new__/__init__
being defined and calling the s
p for the test script fiddles with os.path, but adodbapi itself
makes no changes to sys.modules nor os.path.
On Mon, Aug 10, 2009 at 5:29 PM, Dino Viehland
mailto:di...@microsoft.com>> wrote:
Does adodbapi publish something into sys.modules under the name adodbapi during
i
ters.Item[0]
p.AppendChunk(b) # this is the error line
ra = System.Reference[int]()
rs = cmd.Execute(ra)
count = ra.Value
print 'Returned rowcount=',count
--
Vernon
On Mon, Aug 3, 2009 at 5:33 PM, Dino Viehland
mailto:di...@microsoft.com>> wrote:
Ok, I've finally got SQL ser
cument XAML syntax highlighting and
> restructured text
>
> Dino Viehland wrote:
> > Michael wrote:
> >
> >> Nope, no class definitions - it just uses .NET functionality. It's a
> >> very short bit of code really - 77 lines of which 30 lines are a
> >>
Michael wrote:
> The functions with 17 arguments that don't work... This is how you call
> docutils programatically. I can trigger the bug with the rst2html.py
> scripts but to dig into what is calling it I really want to call the
> APIs directly.
Ahh, yes, an easy work around would be to pass one
It looks like this code is hosted somewhere. So who is catching the
exception in this case? If it's you then you can do:
pythonEngine.GetService().FormatException(exception);
to get a standard Python version of the stack trace.
W/o doing that the .NET stack trace is basically useless. Sometim
As we're winding down towards RC1 and I wanted to do one last check to see if
there's a must-fix bug that we've somehow missed. Based upon our own triage,
the number of votes, etc... it's entirely possible that we've de-prioritized an
important bug that might enable a new scenario, make an exis
What language are you doing this from?
ScriptEngine.Execute has an overload which is generic and an overload
which is not generic. The generic version will get the result and
convert it to the provided generic type. It looks like for some reason
you end up trying to call the generic version here
ython and MAXScript (native 3ds
> Max scripting language).
>
> I have no idea how to access the generic/non-generic engine, further
> more, I have no idea what the difference is.
>
> As for scope, I can do that, the problem is, I have no idea how exactly
> to do that. Is there a
We haven't implemented support for more than 3 parameters :)
In 2.6 I just fixed > 3 params for the Invoke case (not InvokeMember)
and I can fix > 3 for InvokeMember/CreateInstance as well before
2.6 ships.
The preferred way to do this though is to do a GetMember where
T is a delegate type with >
What version of IronPython are you using? Have you ngen'd the binaries?
Ngen will significantly reduce the amount of private working set IronPython
uses.
I assume you don't have a "site.py" or the standard library present or I
think it'd probably be more.
On my machine (some post-RC1 Windows 7 b
line
ra = System.Reference[int]()
rs = cmd.Execute(ra)
count = ra.Value
print 'Returned rowcount=',count
--
Vernon
On Mon, Aug 3, 2009 at 5:33 PM, Dino Viehland
mailto:di...@microsoft.com>> wrote:
Ok, I've finally got SQL server setup in a reasonable state where I can try and
What Curt says is true but I would suggest doing scriptRuntime.LoadAssembly
instead.
Once you do that you can do engine.ImportModule (an extension method defined in
the Python class) do get a ScriptSource for any of your compiled modules.
InitializeModule may change from major version to major
That's convenient because I've been working on fixing that one along
w/ another related bug for getting PyDev debugging to work.
This one will require that you provide a -X:Tracing command line flag
so that we always have the tracing code gen. But it works on my machine
as of a couple of days ago
Compile on 64-bit? :)
I have a guess of what the problem is here but I haven't run a test to
Confirm. I recently ran into a similar issue when I increased the
number of constants we were generating - except for I was just trying
to pre-compile a single file.
If you want to build from source you
: [IronPython] InvokeMember with three or more parameters.
Hello.
Thank you for answer.
How can I create script object without code generation same like:
scriptEngine.Execute(string.Format("{0}()","Broker"),scriptScope);
?
Dino Viehland wrote:
> We haven't imple
Are you compiling w/ the "/target:winexe" option? You'll need to provide that
for doing WinForms development.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of David Escobar
Sent: Wednesday, August 19, 2009 11:03 AM
To: Discussion of IronPython
Su
It is fixed in 2.6. I don't see another bug on this anywhere else
so the new bug will be good to keep around for 2.0.3.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, August 19, 2009 3:44
thon 2.0.2\ipy.exe" pyc.py
> /out:FolderBrowserDialogTest
> /main:FolderBrowserDialogTest.py /target:winexe
> FolderBrowserDialogTest.py*.
>
> The dialog window does come up with every control except
> the tree view
Is there a reason you can't just call FormatException for both cases?
Depending on how the exception is propagated there may be more data in the
exception Data property which we need to pick out and format to accurately
display it.
-Original Message-
From: users-boun...@lists.ironpytho
IronPython import time remains much slower than CPython. I think you've seen
from the differences between 2.0 and 2.6 that we've already made significant
progress in improving this - and we certainly plan to continue pushing on it
with each release.
One way to improve startup time today is to
Kanryu
> Sent: Thursday, August 20, 2009 8:09 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] How to get stack traces from runtime
> exception with using generators.
>
> 2009/8/21 Dino Viehland :
> > Is there a reason you can't just call FormatExceptio
runpy is setting __package__ to an empty string. Looks like CPython doesn't
warn when the string is empty because if I do:
import runpy
x = runpy.run_module('foo', run_name = '__main__', alter_sys=True)
CPython doesn't warn. So the fix is easy enough.
But it's interesting CPython no longer call
You need to override and call the base __new__ instead of __init__. .NET has a
simpler construction model than Python does and __new__ is what best
corresponds to .NET constructors.
class Derived(Test.Base):
def __new__(cls, i):
return Test.Base.__new__(cls, i)
d = Derived()
From
ubject: Re: [IronPython] Constructors & inheriting from standard .NET
> classes
>
> Dino Viehland wrote:
> > You need to override and call the base __new__ instead of __init__.
> .NET has a simpler construction model than Python does and __new__ is
> what best corresponds to .N
Is CClassName a public type? It'll need to both have public members and also
be public its self.
If that's not the problem I'm having trouble understanding exactly what's going
on. Is "return class.doSomething(parameter)" supposedly Python code? Or are
you doing this from C#? "class" is a k
To get around the signing issues you can run "sn -Vr
Microsoft.Scripting.ExtensionAttribute.dll" on
your built version if you build it w/ our public key. The public key is in our
source distributions
as "MSSharedLibKey.snk".
I had intended for 2.6 to be lined up w/ the previously shipped extens
I've generated the 0.9 and 2.0 versions for 2.0 and 2.6 and attached them:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=19126
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Dino V
You might be able to use al.exe to link them together - but otherwise no. Is
the problem having both Main.dll + Main.exe (which we could presumably fix)?
Or is it just the large number of assemblies overall?
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:
1. Generating executables out of IronPython script (Prabhu Mohan)
2. Re: Generati
Yes. CallTarget's were really a part of IronPython's internal calling
convention for used defined functions. We kept CallTarget0 around because we
knew lots of users had come to depend on that one when they needed a delegate
type. But we removed all the others and switched to using Func<...>
Michael Foord wrote:
> I can report this issue to the django guys. I'm still interested in
> making sure that the other problems you reported are entered as
> codeplex
> issues if necessary (please).
Jeff Hardy might also already have a fix for this issue over at:
http://bitbucket.org/jdhardy/dja
Zach Crowell wrote:
> Here's a simple repro of the Evoque re issue. Unfortunately, the error
> doesn't give any indication on what regex caused the failure, and I
> can't really take a look.
>
> D:\>ipy
> IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.3053
> Type "help", "copyright", "credits
dippim wrote:
> The compile works fine and I can execute the resulting test.exe fine
> UNLESS I remove the original test.py file from the directory the
> test.exe file is being executed from. If I remove the test.py file,
> the program crashes. If I put it back, then everything is fine
> again.
>
In Python speak it's importing. Python has very rich import semantics and has
multiple ways of being hooked. Here's some info on that
http://wikikk.com/doc/2.3/whatsnew/section-pep302.html. That'll leave all the
normal file system access there (for things like the standard library) and
still
Filed as 24576
(http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24576)
I don't know that it'll get fixed for 2.6 (although I will take a look). But
I think keyword arg calling needs some general work post-2.6 so that
polymorphic and megamorphic cases work faster and this fix could
Michael wrote:
> It's a nuisance for the Python Tutorial, which gives an example of what
> happens when you call a function incorrectly and the error message from
> IronPython is both different and confusing. :-)
The good news then is that it does look easy to fix :)
Can you include a little more information? Such as the stack trace
of the exception and what the code is doing when it happens?
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of KATO Kanryu
> Sent: Wednesday, Septem
Is it working now for you w/ the Frames = true in the options
then?
For the RC we have a fixed versions of the std lib (thanks to
Michael Foord for fixing it upstream) and we're going to give
a specific error message when _getframe is accessed from sys
but the frames option isn't enabled.
> -
; Ok cool. I've used Func<> from C# before. That did the trick. Thanks.
>
>
> On Tue, Sep 1, 2009 at 6:19 PM, Dino Viehland
> mailto:di...@microsoft.com>> wrote:
>>
>> Yes. CallTarget's were really a part of IronPython's internal calling
>> conve
This looks like final tweaks for the 2.6 release. Other ones have just been
missing "codeplexcomment" in the rush to get the final 2.6 changes in.
In general the changes over the past few weeks have been:
A handful of final bug fixes
Moving a large amount of Microsoft.Scripting.d
One option is to define __slots__ on your classes and not include __dict__ in
the list of slots. This will limit the attributes you can store on the object
and the objects will all be stored in an array instead of a dictionary.
__slots__ should include each attribute you want to be able to set
You're probably missing a reference to System.Windows.Input, doing:
clr.AddReference('System.Windows.Input')
will probably make it work.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Nick Hird
Sent: Friday, September
Because this is on a per-module basis calling GetClrModule() won't affect the
module you later want to do .ToString from.
I think the easiest way to do this would be to do:
var code = Engine.CreateScriptSourceFromString("import clr",
SourceCodeKind.Statements).Compile();
and whenever you want
sult);
}
I'm not convinced if it's working because I'm unsure what GetClrModule()
precisely does or how many scopes there can be, or if there's really
only one scope and everything is additive, or...
Dino Viehland wrote:
> Because this is on a per-module basis call
It’s going to disable JIT optimizations on the individual method. This was
added because we were seeing some differences between release builds and debug
builds around floating point math. We need to track down the real issue but
it may just be a CLR bug that doesn’t affect Mono (or maybe it’
I pinged Fabio off the list to see if he thought this combination should
work.
He says he'll take a look at it over the weekend. If it's something on
our side I think we'd fix it in the final release or put out a new RC.
> -Original Message-
> From: users-boun...@lists.ironpython.com [ma
> There's a couple of places in NWSGI where I need a CodeContext, so
> I've just been creating an empty one like so and using it (and it's
> worked so far):
> new CodeContext(new Scope(),
> HostingHelpers.GetLanguageContext(engine))
>
> Now, in 2.6 RC I need a PythonDictionary instead of a sco
> Hi IronPython team,
> I don't know if this is even an issue, but I'd like to make a request
> for the IronPython 2.6.x releases - please do not change the
> AssemblyVersion from 2.6.0, or make any ABI breaking changes. I'll
> admit, this is mostly because of my own laziness; I don't want to have
Michael wrote:
> I've had to use these several times and they are also used in Ironclad.
> Documentation, *especially* of the changes, would be very useful.
We're going to spend some time in the next couple months on writing and
packaging up some useful documentation. This is definitely one are
Dave wrote:
> Hi, I'm wondering what it would take in theory to get IronPython
> working on MonoTouch (http://monotouch.net/) - the framework for
> writing iPhone apps in C#.
>
> By that I mean that I'm trying to understand the technical obstacles
> that would need to be overcome and possible ways
You should see performance benefits especially if there's a large number of
types subclassed during startup. I'd also recommend ngen'ing the resulting
assembly.
Also clr.GetSubclassedTypes() will return you a list of types which
you have subclassed so far. It's designed to round trip w/
Compile
> I looked at it yesterday, and 'impossible' would be a better way to
> describe it. Some types have moved between assemblies (from
> Microsoft.Scripting to Microsoft.Dynamic) and so simply changing the
> assembly bindings won't work. There were also some API changes that I
> need to fix before NWS
VB, and the CLR in general, has supported named parameters since .NET 1.0.
It's just C# that's finally getting support in .NET 4.0.
Otherwise I think the Dark Corners looks great!
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com]
Yep, sorry for not responding back earlier.
Fabio took a look and basic debugging worked for him. But there were
some problems w/ multiple threads still. Fabio reported this previously
and while I thought I had fixed it there were still some intermittent
failures. I've got a new fix checked int
I actually ran into this last night and have a fix for it which will
be in RC2.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, October 05, 2009 4:58 AM
> To: Discussion of IronPython
Michael wrote:
> I'd love to see IronPython 3 as a separate DLR language that could be
> used alongside IronPython 2.X. That way an IronPython 2 engine could use
> IronPython 3 engines and vice versa. This would allow Python 3 apps to
> use Python 2 libraries (with a wrapper layer) and vice-versa,
Michael wrote:
> We're working on the port of Resolver One to IronPython 2.6. We're
> finding that in quite a few of our tests our documents are now not being
> garbage collected, which would be a major memory leak in Resolver One if
> left unaddressed.
>
> As far as we can *tell* what is keeping
Michael wrote:
> Can one process load different versions of the same assembly? I thought
> that wasn't possible.
Yep! Effectively everyone's favorite "Cannot cast A to A" exception is
a variation on doing this :)
___
Users mailing list
Users@lists.iro
> *However*, we discovered that we inadvertently had options["Frames"] =
> true; in the code that creates the main engine. Switching that off (and
> then having to recompile all our Python code) solved the problem.
>
> It may indicate that if we want to turn frames on in individual engines
> (each
Michael wrote:
> The recompiling issue is slightly concerning as well. Is it the case
> that if we compile all our libraries with Pyc with frames off then we
> can't use them from an engine with the tracing / frames / debugging
> options on (taking advantage of frames and debugging support)?
Unfo
801 - 900 of 2031 matches
Mail list logo
