[IronPython] Resolver One 1.4 beta - with IronPython 2.0

Thu Feb 5 00:06:58 CET 2009

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