I'm sorry if I wasn't clear, but the IP team's stance on this is totally acceptable, I wasn't nudging anyone to do anything.
Personally, I think that such "improvements" should go into IPCE or some other community type extensions project. As we stand today, IP doesn't really work flawlessly on Mac/Linux anyway. Patches need to be plugged for all kinds of quirks such as console support etc. Mind you, that "we" got into this state without any P/Invoking (referring back to "Write once, debug everywhere") I don't expect anything coming off the IP team to work on anything other than MS.NET/SilverLight. It's up to the community to pick it up from there on. On Thu, Feb 5, 2009 at 1:06 AM, Dino Viehland <di...@microsoft.com> wrote: > Where "make it easier" is really "make it an acceptable cost". > > While a feature may have taken just a day for you to implement Dan it also > has on-going costs. Every feature inevitably has bugs and those bugs need > to be fixed. If we need to implement both the feature from the Python side > plus the underlying functionality it's only going to have a higher on-going > cost. Even if the code is 100% bug free there's still on-going costs as the > rest of the code base changes around it. And even if we were to resolve > those and say we won't fix them there's still at least the cost of triaging > those bugs. > > Also adding specific support for Linux or Mac OS/X APIs would imply that we > should be testing those code paths on those platforms. Which means that our > check-in infrastructure that validates and rejects check-ins will also need > to be updated to run tests on Linux or Mac OS/X. Not to mention the > potential distraction of "Why didn't you support FreeBSD?", "Where's my OS/2 > support?", "What about ReactOS?" or someone else's favorite platform. > > Another additional consideration is that IronPython today is 100% safe & > security transparent code. That means when we need to ask the question "Can > IronPython be used to elevate permissions?" the answer is simple - it's no. > Once we introduce a P/Invoke, or any other unsafe code, we will then need > to deal with "Did that API that requires trust get implemented correct?". > It's much easier to rely upon .NET getting the security right so we can > focus on the problems that our users directly care about. > > So I'd say that one day quickly gets blown up into a lot of time most of > which can be saved if we have the feature implemented for us in the platform > we run on which happens to be .NET. > > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] On Behalf Of Slide > Sent: Wednesday, February 04, 2009 2:13 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 > > That's true, but if the low-level bindings are in the framework > itself, rather than a consumer of the framework, it does make it > easier to port to other platforms which have the same API that wrap > the low-level bindings at the framework level. > > > On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter <d...@houmus.org> wrote: > > I beg to differ... > > Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it > > really boils down to who maintains the "low-level" bindings... > Ultimately, > > without pinvokes you wouldn't be able to accomplish anything... > > > > If I was able to get mmap working on Linux/windows/macosx x86/x64 in one > day > > then I'm sure it can't be that much of a problem... > > > > Beside managed runtimes like python/.net/java were never about being > > platform agnostic, 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 <slide.o....@gmail.com> wrote: > > > >> I think that is a great plan. Having no P/Invokes makes it much more > >> platform agnostic. > >> > >> > >> > >> On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland <di...@microsoft.com> > wrote: > >>> > >>> Current thinking is that IronPython 3k will be the 1st version that > will > >>> take a dependency on .NET 4.0 so we'll have to wait until then. Having > >>> to > >>> rely on P/Invoke is one of the main reasons we don't have this yet > >>> (IronPython doesn't have any p/invokes today and we'd like to avoid > them > >>> if > >>> at possible). > >>> > >>> > >>> > >>> From: users-boun...@lists.ironpython.com > >>> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter > >>> Sent: Wednesday, February 04, 2009 1:04 PM > >>> To: Discussion of IronPython > >>> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 > >>> > >>> > >>> > >>> I know :) > >>> I have my own C# Assembly that does mmap() on Windows/Linux with > PInvoke. > >>> > >>> I did notice though that .NET 4.0 WIll have "native" support for mmap() > >>> through System.IO.MemoryMappedFiles... > >>> So perhaps IP 2.X will add that as well... > >>> > >>> > >>> On Wed, Feb 4, 2009 at 12:15 PM, William Reade > >>> <will...@resolversystems.com> > >>> wrote: > >>> > >>> I should point out ahead of time that there's no mmap module in > >>> IronPython > >>> at the moment, and so memory-mapped ndarrays don't work yet -- although > >>> most > >>> of the usual numpy save/load bits do work, so you'll probably be fine > >>> (unless they're too big to fit in memory). > >>> > >>> Dan Shechter wrote: > >>> > >>> Here! > >>> > >>> I can't wait to use it with NumPy. > >>> > >>> I actually have a .NET C# assembly that does some really nasty > low-level > >>> stuff like loading data from memory mapped > >>> files and wrapping them with IList<T> :) > >>> > >>> I can't wait to make Ironclad/Numpy blow up :) > >>> > >>> > >>> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas > >>> <giles.tho...@resolversystems.com > >>> <mailto:giles.tho...@resolversystems.com>> > >>> wrote: > >>> > >>> Hi all, > >>> > >>> Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on > >>> IronPython 2.0, and includes (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 trying it out, drop me a line! > >>> > >>> > >>> Best regards, > >>> > >>> Giles > >>> -- > >>> Giles Thomas > >>> MD & CTO, Resolver Systems Ltd. > >>> giles.tho...@resolversystems.com > >>> > >>> <mailto:giles.tho...@resolversystems.com> > >>> > >>> +44 (0) 20 7253 6372 > >>> > >>> Win up to $17,000 for a spreadsheet: > >>> <http://www.resolversystems.com/competition/> > >>> > >>> 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 <mailto:Users@lists.ironpython.com> > >>> > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Shechter. > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> 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 > >>> > >>> > >>> -- > >>> > >>> Shechter. > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users@lists.ironpython.com > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>> > >>> > >> > >> > >> > >> -- > >> slide-o-blog > >> http://slide-o-blog.blogspot.com/ > >> _______________________________________________ > >> 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 > > > > > > -- > slide-o-blog > http://slide-o-blog.blogspot.com/ > _______________________________________________ > 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 > -- Shechter.
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
