Hi All,
This is not a SPAM. It's a one time message to all...
This may be wrong place to introduce my blog.
If you are interested in technical knowledge sharing and wanted to know
about new software's and more,
Just visit
http://www.aloysiusjegan.com/blog/
If you find this blog will be useful f
This brings up another question I've encountered. My understanding was that
IPy had problems with 3.5, and so I have been targeting 2.0. But when I try
to reference the IronPython and Microsoft.Scripting assemblies, Visual
Studio says I need 3.5
On Wed, Jun 17, 2009 at 6:05 PM, Curt Hagenlocher
Good point!
On Wed, Jun 17, 2009 at 5:12 PM, Michael Foord wrote:
> Curt Hagenlocher wrote:
>
>> ...except through the hosting API *and through the new C# dynamic
>> functionality in .NET 4.0*.
>>
>
> And how do you get to the classes to use them with the new dynamic
> functionality if it isn't t
There are so many different .NET versions -- I suppose that somewhere in
msdn there is an explanation of the differences -- but I have often wondered
why IronPython used 2.0 when 3.5 is available. Just idle curiosity, I don't
really care, but if there are significant new features, will IronPython 2
Curt Hagenlocher wrote:
...except through the hosting API *and through the new C# dynamic
functionality in .NET 4.0*.
And how do you get to the classes to use them with the new dynamic
functionality if it isn't through the hosting API?
What you do with them once you get them is your own busi
...except through the hosting API *and through the new C# dynamic
functionality in .NET 4.0*.
On Wed, Jun 17, 2009 at 5:06 PM, Michael Foord wrote:
> Justin Regele wrote:
>
>> What is the status of referencing IPy libraries compiled to dlls by other
>> CLR languages? Google turned up that as of 1.
Justin Regele wrote:
What is the status of referencing IPy libraries compiled to dlls by
other CLR languages? Google turned up that as of 1.1 you had to use
the embedding/hosting api's, since the dlls were not compatible with
say C# assemblies. There were allusions made to this being changed.
For a moment it looked like it would work. I can instantiate an object from
my module, which showed up in intellisense, but can't access any of the
methods within the object.
Oh well. embedding it is.
On Wed, Jun 17, 2009 at 4:48 PM, Slide wrote:
> I would think that you would always need the D
I would think that you would always need the DLR at least because of
the references that the "compiled" dlls would have.
On Wed, Jun 17, 2009 at 4:45 PM, Justin Regele wrote:
> What is the status of referencing IPy libraries compiled to dlls by other
> CLR languages? Google turned up that as of 1.
What is the status of referencing IPy libraries compiled to dlls by other
CLR languages? Google turned up that as of 1.1 you had to use the
embedding/hosting api's, since the dlls were not compatible with say C#
assemblies. There were allusions made to this being changed.
__
Looks like this is because type.__module__ is not a data descriptor.
I believe I have a fix.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Seo Sanghyeon
Sent: Wednesday, June 17, 2009 3:04 AM
To: Discussion of IronPyt
I have developed a Silverlight application that uses IronPython to
dynamically generate and execute a script. The script is dependent on
data supplied by the user and can be computationally expensive so it's
run on a separate thread. I need an option for the user to abort the
script in case it hang
Or there's always:
import nt
import errno
for x in dir(errno):
val = getattr(errno, x)
if type(val) is int:
print ('case PythonErrorNumber.%s: return "' + nt.strerror(val) +
'";') % x
:)
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun.
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from
http://ironpython.codeplex.com/SourceControl/changeset/view/54926.
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Dis
Hi!
IronPython has poor support of COM techno. In particular, IP can not use
dynamic COM servers (perhaps because they do not have TLB?).
Now, cPython is good to create dynamic COM servers (see Python Programming
on Win32, page 219 & +).
Thus, ironPython is bad, to use the COM servers made
Following program prints different result between CPython and IronPython:
def f(): pass
print type(f).__module__
CPython: __builtin__
IronPython:
This breaks codes which assume __module__ is a string.
--
Seo Sanghyeon
___
Users mailing list
Users@li
os.strerror is not implemented. Something as simple as the following woud work:
import os
import errno
def strerror(code):
if code == errno.ENOENT:
return 'No such file or directory'
elif code == errno.EACCES:
return 'Permission denied'
else:
return 'Unknown er
17 matches
Mail list logo
