Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Dino Viehland]

+1 on the MC++, this seems like an ideal use of it.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Friday, October 12, 2007 11:38 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcement: Project to get some CPython C 
extensions running under IronPython

On 10/12/07, Giles Thomas <[EMAIL PROTECTED]> wrote:

What is the best architecture?  We're thinking of this as being a bit of C# 
managed code to interface with the C extension, and a thin Python wrapper on 
top.  The module's existing C extension and Python code would "sandwich" this 
layer.  Let us know if this is a silly idea :-)
My two cents would be this: using Managed C++, try for source compatibility 
first.  It will almost certainly be less work than binary compatibility -- 
especially given your restricted test case -- and you're not likely to do much 
coding that wouldn't be needed for binary compatibility anyway.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Dynamic Language Runtime Position

[Dave Fugate]

I'd like to announce that the Dynamic Language Runtime team (IronPython and 
IronRuby) currently has an opening for a 'Software Development Engineer in 
Test'.  Quite simply put our team is  in need of another tester with a strong 
interest in dynamic languages and a background in Python or Ruby.  A detailed 
job description can be found at 
http://members.microsoft.com/careers/search/details.aspx?JobID=34EDBF1A-395B-4BD7-8811-AC68BD4EFB0C
 and John Lam's blog has some more info as well - see http://www.iunknown.com/. 
 Some of tasks you might work on include:

* Testing the compatibility of IronPython/IronRuby w/ CPython/MRI

* Writing tests which exercise DLR functionality.  For example, you 
might try to write a C# application which executes Python/Ruby code via the 
DLR's hosting APIs

* Creating 'real world' dynamic Silverlight applications as a customer 
might to find bugs in the design of the APIs
If you're interested please visit the careers website mentioned above or email 
your resume to [EMAIL PROTECTED] with "DLR SDET 
Position" in the subject field.
The Dynamic Language Runtime Team
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython 2.0 Alpha 5

[Dave Fugate]

Hello IronPython Community,

We have just released IronPython 2.0 Alpha 5.  Over the past month our team has 
been busy fixing bugs which were typically chosen by the number of votes on 
CodePlex.  A little over forty CodePlex Work Items and around twenty bugs 
reported internally were closed since the release of IP 2.0A4.  There were no 
major new features added unless you count the fact that we ported the standard 
'array' module from IronPython v1.1 to v2.0.  This now means that all of the 
standard modules in v1.1 are available in the latest 2.0 tree.

Specifically the following CodePlex Work Items were resolved and I'd like to 
extend our team's thanks to everyone who reported, commented, and voted on 
these:

· 9453ayarrow   += works differently on lists

· 3727bashmohandes Problem when creating new Workflow 
in Windows Workflow

· 1608brucec  str.__dict__['__dict__'] 
should not exist

· 5445IPTeamsocket.getaddrinfo(...) does 
not throw on nonsense parameters

· 5682IPTeamSystem.Single boolean ops w/ 
integer types broken

· 3289IPTeamThreads should not block the 
main thread from exiting

· 10778  sanixyn-S command-line option omits 
"Lib" from sys.path

· 12283  IPTeamsys.argv always empty regardless 
of params passed to ipyw.exe

· 12851  IPTeamExpressions starting with a 
backslash in interactive sessions broken

· 10518  Benjamin Westurllib is failing to work due to 
socket disposed exception

· 11759  sanixynZero-length regex split

· 5641Christian Muirhead co_name in code objects is None

· 5712Jörgen Stenarson iterating over __main__.__dict__ 
throws

· 2599Kurt Blackwell__import__ from list is incorrect

· 12708  David Lawler  Method dispatch fails with 
SharpDevelop APIs

· 12908  Michael Foord Support 0x200 
(PyCF_DONT_IMPLY_DEDENT) for compile built-in function

· 2728sanixynSlicing on old style classes 
is different

· 6735sanixynhelp incorrectly displays 
arguments for params functions

· 7426Sylvain Hellegouarch  in operator doesn't check for 
overloaded __contains__ on dictionary

· 7532sanixynfunc_defaults is empty tuple 
when there are no defaults

· 7594sanixyntype.__call__ always passes 
type(type) as 1st parameter

· 6014Davy Mitchell Calling super on overridden 
property causes stack overflow

· 9066Michael Foord IronPython won't look into 
arbitrary objects when doing import

· 5602Eloff(Py2.5) Cannot import random

· 12455  eshaish Importing PYD files

· 5204gbraad PowerShell hosting IronPython

· 11684  googenPythonEngine has no constructors 
defined

· 9262grizlupo   not override __eq__ at derived 
float

· 7279haypo  It's not possible to check is 
a string is 'str' or 'unicode'

· 7918jackeyoo  CPython has the functions below 
while IronPython does not implement them

· 10058  johnplatt  cPickle module doesn't work for 
xrange

· 6489IPTeamBackslash on the interactive 
console causes syntax error

· 5690Oceanborn   Different parsers, compiler 
pipeline?

· 6332pobrienDataGridView doesn't support a 
list of Python class instances as its DataSource

· 5799pobrienUnpickler.persistent_load 
needs to be supported

· 3078psykotic   Bug when dealing with 
importing of .NET assemblies with class named identically to its containing 
namespace

· 3410sanxiynyield in nested try blocks

· 11812  tscottwdir(bool), dir(True), 
dir(False) raise SystemError on startup

· 10904  tscottw[Affecting Tutorial on 2.0] 
Missed feature (optional arguments) in exercise 2.1 in Tutorial 3

· 7982whit537   ^L yields SyntaxError

IMPORTANT NOTE
Internally we have migrated our Visual Studio project and solution files over 
to a Visual Studio 2008 beta release.  While we've modified these files in the 
source distribution of IronPython to be compatible with Visual Studio 2005 and 
the msbuild tool, it's pos

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Curt Hagenlocher]

On 10/12/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
>
> What is the best architecture?  We're thinking of this as being a bit of
> C# managed code to interface with the C extension, and a thin Python wrapper
> on top.  The module's existing C extension and Python code would "sandwich"
> this layer.  Let us know if this is a silly idea :-)
>
My two cents would be this: using Managed C++, try for source compatibility
first.  It will almost certainly be less work than binary compatibility --
especially given your restricted test case -- and you're not likely to do
much coding that wouldn't be needed for binary compatibility anyway.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
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

[Keith J. Farmer]

NumPy would be cool :)  And it probably gives you a few different data 
structures to figure out marshalling, no?



From: [EMAIL PROTECTED] on behalf of Giles Thomas
Sent: Fri 10/12/2007 10:00 AM
To: Discussion of IronPython
Subject: [IronPython] Announcement: Project to get some CPython C extensions 
running under IronPython


At Resolver Systems, we started building our core products with the view that 
most of our clients would want to use them to connect spreadsheet data and 
designs, Python code, and .NET objects.  This was the right decision; lots of 
people do want to do just that, and we've been working with them so far.

However, as we've spoken to more potential clients over the last months, we've 
learned something new - that there's a lot of interest out there in using a 
tool like Resolver One to plug together not just spreadsheets, Python and .NET, 
but also the existing CPython C extensions.

Solving the general problem - plugging an arbitrary C extension into IronPython 
- is a huge project, and we're not even sure we could work out *how much work 
it is* without a lot of investigation.  What we intend to do is to solve a 
specific problem, to integrate just one extension, and to use that project as a 
testbed to examine the possibilities for getting other extensions working - and 
perhaps, in the long term, solving the general problem.

We think that any solution like this will be valuable not just to us, but to 
the IronPython community as a whole.  And so, we want to make it Open Source.

Right now, we'd particularly like to hear from people about the following:


*   Who wants to get involved?  We're really keen on working with people on 
this.

*   Which module should we go for?  NumPy looks like a good start, as it 
gives us a start on getting SciPy working.  But perhaps there are better 
choices. 
*   Should this be a new project, or should we be talking to other people 
about getting it into other projects? 
*   Which license?  If we're to work on it with a view to building it into 
Resolver One, then it will need to be commercial-software-friendly.  Apart from 
that - we have no view.

*   What is the best architecture?  We're thinking of this as being a bit 
of C# managed code to interface with the C extension, and a thin Python wrapper 
on top.  The module's existing C extension and Python code would "sandwich" 
this layer.  Let us know if this is a silly idea :-)

*   Is there anything else we should be thinking about to get this started?



Regards,

Giles

-- 
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/ 

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
<>___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

At Resolver Systems, we started building our core products with the view 
that most of our clients would want to use them to connect spreadsheet 
data and designs, Python code, and .NET objects.  This was the right 
decision; lots of people do want to do just that, and we've been working 
with them so far.


However, as we've spoken to more potential clients over the last months, 
we've learned something new - that there's a lot of interest out there 
in using a tool like Resolver One to plug together not just 
spreadsheets, Python and .NET, but also the existing CPython C extensions.


Solving the general problem - plugging an arbitrary C extension into 
IronPython - is a huge project, and we're not even sure we could work 
out *how much work it is* without a lot of investigation.  What we 
intend to do is to solve a specific problem, to integrate just one 
extension, and to use that project as a testbed to examine the 
possibilities for getting other extensions working - and perhaps, in the 
long term, solving the general problem.


We think that any solution like this will be valuable not just to us, 
but to the IronPython community as a whole.  And so, we want to make it 
Open Source.


Right now, we'd particularly like to hear from people about the following:

   * Who wants to get involved?  We're really keen on working with
 people on this.
   * Which module should we go for?  NumPy looks like a good start, as
 it gives us a start on getting SciPy working.  But perhaps there
 are better choices.
   * Should this be a new project, or should we be talking to other
 people about getting it into other projects?
   * Which license?  If we're to work on it with a view to building it
 into Resolver One, then it will need to be
 commercial-software-friendly.  Apart from that - we have no view.
   * What is the best architecture?  We're thinking of this as being a
 bit of C# managed code to interface with the C extension, and a
 thin Python wrapper on top.  The module's existing C extension and
 Python code would "sandwich" this layer.  Let us know if this is a
 silly idea :-)
   * Is there anything else we should be thinking about to get this
 started?


Regards,

Giles

--
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/ 


17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.

Registered address: 843 Finchley Road, London NW11 8NA, UK

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com