[IronPython] Resolver One 1.4 beta - with IronPython 2.0

Dan Shechter dans at houmus.org
Thu Feb 5 00:27:20 CET 2009


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 <dinov at 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-bounces at lists.ironpython.com [mailto:
> users-bounces at 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 <dans at 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.mix at 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 <dinov at 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-bounces at lists.ironpython.com
> >>> [mailto:users-bounces at 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
> >>> <william at 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.thomas at resolversystems.com
> >>> <mailto:giles.thomas at 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.thomas at resolversystems.com
> >>>
> >>>  <mailto:giles.thomas at 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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> >>>
> >>>  http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>  Shechter.
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.ironpython.com
> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.ironpython.com
> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>
> >>> --
> >>>
> >>>  Shechter.
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at 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 at lists.ironpython.com
> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > _______________________________________________
> > Users mailing list
> > Users at 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 at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 

   Shechter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090205/c0758c46/attachment.html>


More information about the Ironpython-users mailing list