It's not what I assumed. Most .NET applications in my experience don't package
the framework when they're distributed. In fact, I tend to feel offended when
I find an app has packaged the entire runtime it needs and included it in the
install. Zope really annoyed me in this way, and don't get
Well i am sure that when python 3000 comes out iron python will be there
with there version!
On 1/23/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
We haven't had much in the ways of discussing supporting Py3k features yet
and it might still be a little too early to do so. We have been following
Dino Viehland wrote:
> We haven't had much in the ways of discussing supporting Py3k features yet
> and it might still be a little too early to do so. We have been following
> some of the changes and we'll probably start following the changes a little
> more closely.
>
> We also still have some
Keith J. Farmer wrote:
> I was just latching myself onto the shipping-binaries-only blurb in the
> original email. :)
>
> My personal biases are against shipping source code, if for no other reason
> than it avoids the problems of office-chair programmers modifying code they
> don't actually u
Dino Viehland wrote:
> This should be solvable in a similar but slightly different way. We wouldn't
> want to require an extra argument (in this case the versioned IronPython
> engine) to be required for each call. Also I'm going to pick a slightly more
> generic example "DoOperation" instead
We haven't had much in the ways of discussing supporting Py3k features yet and
it might still be a little too early to do so. We have been following some of
the changes and we'll probably start following the changes a little more
closely.
We also still have some catching up to do with v2.5 (1.
I was just latching myself onto the shipping-binaries-only blurb in the
original email. :)
My personal biases are against shipping source code, if for no other reason
than it avoids the problems of office-chair programmers modifying code they
don't actually understand. That, and the deploymen
If it did, I don't think we'd be getting the continuous updates.
Thought some more on the commute. The are a couple problems, overall, when
versioning.
The basic problem I think is avoiding the dll explosion when maintaining
side-by-side versions that are frequently updated. The explosion c
It might be interesting to also run with -X:ExceptionDetail to see where the
exception is coming from and report that back to the Mono team.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Haibo Luo
Sent: Tuesday, January 23, 2007 9:05 AM
To: Discussion o
This should be solvable in a similar but slightly different way. We wouldn't
want to require an extra argument (in this case the versioned IronPython
engine) to be required for each call. Also I'm going to pick a slightly more
generic example "DoOperation" instead of Add (because a bug fix to
When/If IronPython becomes stable won't IronPython.dll just disappear into the
.NET runtime?
- Original Message -
From: Keith J. Farmer
To: Discussion of IronPython
Sent: Tuesday, January 23, 2007 1:00 PM
Subject: Re: [IronPython] Feedback neededfor bug fix:Import
pre-compiled
I could be wrong (I certainly have been in the past), but the current scheme
seems to pre-empt the built-in mechanisms.
There are several ways you can get a reference to an assembly -- file name,
name space without strong name, name space and version, name space and public
key, etc. This works
I did not see the repro in ironpython + .net.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Monday, January 22, 2007 11:26 PM
To: Discussion of IronPython
Subject: [IronPython] Problems with -X:SaveAssemblies
I found this while testi
I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has
to use the same centrally maintained copy of a DLL" the recipe for "DLL hell"
that .Net is supposed to let us avoid? In the specific scenario you provide --
you update a DLL used by an existing EXE -- .Net is design
CPython
>>> type.__call__(object)
IronPython
>>> type.__call__(object)
Something's wrong...
--
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
15 matches
Mail list logo
