[IronPython] New Mailing List is now available

[Jeff Hardy]

Hi all,
After the downtime yesterday, the new mailing list is now available.
It appears that everyone has received unsubscribe notices; these were
sent in error. Everyone who was subscribed to the old list should be
subscribed to the new list.

The page for the new list is
http://mail.python.org/mailman/listinfo/ironpython-users, and mails
should now be sent to ironpython-us...@python.org.

If you think that you are not getting mail, please send me an email
directly and I will verify that you are still in the membership
database.

Also, a big thank you goes out to DreamHost, Jim Hugunin, and Ralf
Hildebrandt for their work in getting the mailing list moved over.

Again, I apologize for any inconvenience this may have caused, and for
the erroneous unsubscribe messages.

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

Re: [IronPython] Upcoming Mailing List Changes

[Jeff Hardy]

On Tue, Jun 14, 2011 at 9:20 AM, Jeff Hardy  wrote:
> The timeline hasn't been established...

It looks like the move is going to go ahead tomorrow (Wednesday) or
the next day. Remember, list traffic will be coming from
ironpython-us...@python.org, and mails need to be sent to that address
as well. Also, the new list does not enable Reply-To munging (for all
the reasons in http://marc.merlins.org/netrants/reply-to-harmful.html).

If you want your email to be in the archives, wait a couple of days
until we're sure that everything has gone smoothly. I'll send a
notification when the move is complete, and then any mails to the list
have to go to the new address.

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

[IronPython] Upcoming Mailing List Changes

[Jeff Hardy]

Hi all,
This a notice that some changes may be coming to this mailing list in
the near future.

I'm planning on moving the list from it's current host (by a gracious
IronPython community member) to being hosted on python.org. The
address of the list will change from users@lists.ironpython.com to
ironpython-us...@python.org. Ideally all of the subscribers and
archives will be transferred over as well, but that's still being
sorted out. The old list address should also be usable for a while as
well.

The timeline hasn't been established, but I'll let you know when the
expected transition is. Ideally, it will all be seamless, but if you
have any mail filters based on the old address, you'll have to update
them.

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

Re: [IronPython] Seattle IronPython Meetup

[Jeff Hardy]

OK, follow up questions:

* When? Sometime this coming week would work great for me; what about
anyone else?

* What times work best? Either weekends or evenings are fine by me.

* What format? Right now I'm thinking that we actually plan it as a
sprint, with perhaps a couple of lightning talks thrown in.

* Who's coming? A few people have indicated interest; I'd like to have
a half-dozen or so committed people. I'd also like to get some newbies
there; I'm not sure how best to reach out to them.

If there's no rough consensus, I'll just pick a date & time. We'll
probably use Steve Baer's graciously volunteered office, so obviously
Steve has a fair bit of say over the date & time :).

- Jeff

On Fri, Jun 10, 2011 at 10:42 AM, Jeff Hardy  wrote:
> Hi all,
> Is anyone in the Seattle area interested in an IronPython meetup, or
> even a sprint? Anybody fancy a hands-on crash course in how IronPython
> works? Let me know! If enough people are interested, I'll work
> something out (probably for the coming week).
>
> I'm new to the area, so if anyone has any suggestions on where to
> meet, feel free. I'd prefer to avoid downtown Seattle, unless that
> works for everyone else.
>
> - Jeff
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Seattle IronPython Meetup

[Jeff Hardy]

On Fri, Jun 10, 2011 at 2:17 PM, Steve Baer  wrote:
> Doesn't really matter; we're a pretty laid back company.  We have a meeting
> room that comfortably holds at least 15 (could hold more) with a big screen
> television that we can hook up to.  We actually have the room pretty well
> wired with mics and a soundboard since we hold a weekly Tuesday lunch
> meeting there and include a few co-workers in Europe and in other states
> through skype or teamviewer.

Ooh, nice.

>
> Weekends and evenings are also fine, but if the weather starts getting too
> nice I might not be there to open the door;)

You did say you were in Seattle, right? ;)

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

Re: [IronPython] Seattle IronPython Meetup

[Jeff Hardy]

On Fri, Jun 10, 2011 at 11:16 AM, Curt Hagenlocher  wrote:
> Welcome to Seattle! Or as I like to think of it, welcome to
> June-and-we-still-have-the-heat-on! :(

I'm from Canada, so this is normal (more rain though). I look forward
to not dealing with -40, and laughing at the locals who panic in an
inch of snow. :)

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

Re: [IronPython] Moving forward on 2.7.1

[Jeff Hardy]

Oh, cool. I've only ever used skype for video chats, so I've never
looked at what else it does. I'd never heard of Mikogo, but I'll keep
it in the back of my head because it looks interesting.

- Jeff

On Fri, Jun 10, 2011 at 11:02 AM, Zachary Gramana
 wrote:
> Apparently skype now supports it:
> http://www.skype.com/intl/en-us/features/allfeatures/screen-sharing
>
> I have also had good (cross-platform) luck with the currently-free mikogo
> service: http://www.mikogo.com/
>
> On 6/10/2011 1:56 PM, Jeff Hardy wrote:
>>
>> Skype would work, and if anyone knows of a way to do screen sharing as
>> well, please chime in.
>>
>> Shoot me a mail off list and we'll sort it out.
>>
>> - Jeff
>>
>> On Fri, Jun 10, 2011 at 10:48 AM, Zachary Gramana
>>   wrote:
>>>
>>> That's great to hear.
>>>
>>> On the getting involved note, one thing I would love is a code review
>>> over
>>> ichat/skype/mikogo/cell/etc. I have a patch I intend to submit shortly,
>>> and
>>> would love someone who knows what they are doing to review it with me
>>> synchronously, if nothing else so I can validate some of my assumptions.
>>>
>>>
>>> On 6/10/2011 12:21 PM, Jeff Hardy wrote:
>>>>
>>>> On Fri, Jun 10, 2011 at 8:02 AM, Zachary Gramana
>>>>     wrote:
>>>>>
>>>>> There are some big Python applications (e.g. Mercurial) that are going
>>>>> to
>>>>> remain on 2.7 for some time. There are important modules that are still
>>>>> missing (bz2), or are incomplete (_winreg), that create compatibility
>>>>> barriers.  It would also be nice to have sockets moved to the
>>>>> socket.py/_socket.cs model (similar to how ssl has been implemented) to
>>>>> support apps that monkey patch that module.
>>>>
>>>> 100% agreed. I don't want to see 2.7 whither, for exactly the reasons
>>>> you mention, and there is still a lot of low hanging fruit that could
>>>> make it much better. The thing is, my own interests are drifting to
>>>> Python 3, because I think it will allow IronPython to be as close to
>>>> perfectly compatible as possible. Plus, it will give me a chance to
>>>> really get into the guts of IronPython, which I'm going to document
>>>> more fully as I go.
>>>>
>>>>>
>>>>> I know the community is limited in resources, but I would hope that 2.7
>>>>> not
>>>>> be abandoned too quickly. I would happily volunteer to own the
>>>>> maintenance
>>>>> of 2.7, but I am far too early in the learning curve to be of any
>>>>> practical
>>>>> use.  That said, I'm happy to help on items where I am familiar with
>>>>> that
>>>>> part of the codebase, or where an experienced contributor can give me
>>>>> some
>>>>> mentoring. For example, I'm interested in helping to implement the bz2
>>>>> module using ic#code's #zip lib
>>>>> (http://www.icsharpcode.net/OpenSource/SharpZipLib/), but would
>>>>> definitely
>>>>> need some mentoring along the way.
>>>>
>>>> I will do (almost) whatever I need to to get more people involved in
>>>> this project. Unimplemented or incomplete modules are a great place to
>>>> start (that's how I started). Any assistance (no matter how small) is
>>>> appreciated.
>>>>
>>>> - Jeff
>>>> ___
>>>> 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
>>>
>> ___
>> 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
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Moving forward on 2.7.1

[Jeff Hardy]

Skype would work, and if anyone knows of a way to do screen sharing as
well, please chime in.

Shoot me a mail off list and we'll sort it out.

- Jeff

On Fri, Jun 10, 2011 at 10:48 AM, Zachary Gramana
 wrote:
> That's great to hear.
>
> On the getting involved note, one thing I would love is a code review over
> ichat/skype/mikogo/cell/etc. I have a patch I intend to submit shortly, and
> would love someone who knows what they are doing to review it with me
> synchronously, if nothing else so I can validate some of my assumptions.
>
>
> On 6/10/2011 12:21 PM, Jeff Hardy wrote:
>>
>> On Fri, Jun 10, 2011 at 8:02 AM, Zachary Gramana
>>   wrote:
>>>
>>> There are some big Python applications (e.g. Mercurial) that are going to
>>> remain on 2.7 for some time. There are important modules that are still
>>> missing (bz2), or are incomplete (_winreg), that create compatibility
>>> barriers.  It would also be nice to have sockets moved to the
>>> socket.py/_socket.cs model (similar to how ssl has been implemented) to
>>> support apps that monkey patch that module.
>>
>> 100% agreed. I don't want to see 2.7 whither, for exactly the reasons
>> you mention, and there is still a lot of low hanging fruit that could
>> make it much better. The thing is, my own interests are drifting to
>> Python 3, because I think it will allow IronPython to be as close to
>> perfectly compatible as possible. Plus, it will give me a chance to
>> really get into the guts of IronPython, which I'm going to document
>> more fully as I go.
>>
>>>
>>> I know the community is limited in resources, but I would hope that 2.7
>>> not
>>> be abandoned too quickly. I would happily volunteer to own the
>>> maintenance
>>> of 2.7, but I am far too early in the learning curve to be of any
>>> practical
>>> use.  That said, I'm happy to help on items where I am familiar with that
>>> part of the codebase, or where an experienced contributor can give me
>>> some
>>> mentoring. For example, I'm interested in helping to implement the bz2
>>> module using ic#code's #zip lib
>>> (http://www.icsharpcode.net/OpenSource/SharpZipLib/), but would
>>> definitely
>>> need some mentoring along the way.
>>
>> I will do (almost) whatever I need to to get more people involved in
>> this project. Unimplemented or incomplete modules are a great place to
>> start (that's how I started). Any assistance (no matter how small) is
>> appreciated.
>>
>> - Jeff
>> ___
>> 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
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Seattle IronPython Meetup

[Jeff Hardy]

Hi all,
Is anyone in the Seattle area interested in an IronPython meetup, or
even a sprint? Anybody fancy a hands-on crash course in how IronPython
works? Let me know! If enough people are interested, I'll work
something out (probably for the coming week).

I'm new to the area, so if anyone has any suggestions on where to
meet, feel free. I'd prefer to avoid downtown Seattle, unless that
works for everyone else.

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

Re: [IronPython] Website Update Help

[Jeff Hardy]

> Since our sites are all HTML, might be nice just to use GitHub pages rather 
> than the current GoDaddy hosting, though changing the nameservers through 
> Microsoft will be a pain.

I was considering that as well, but I'm not sure we can have two sets
of pages from one account. I'll poke github and see what our options
are.

I'll also see if there's anyway to transfer the domains from MS. You
might have a better idea of who to ask then I would, though.

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

Re: [IronPython] Website Update Help

[Jeff Hardy]

On Fri, Jun 10, 2011 at 9:49 AM, Jimmy Schementi  wrote:
> I can do it.

Thanks. Make sure you check my fork to make sure it's in sync with yours.

Any objections to using https://github.com/IronLanguages/iron-websites
as the main fork, and doing all of the updates from there?

- Jeff

>
> ~Jimmy
>
>
> On Jun 10, 2011, at 12:36 PM, Jeff Hardy  wrote:
>
>> Hi,
>> I'm wondering if there's anyone out there willing to help update the
>> website, in particular replacing the big "IronPython Tools" banner
>> with something else. Updating it isn't too hard and I'll offer any
>> assistance that may be necessary.
>>
>> - Jeff
>> ___
>> 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
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Website Update Help

[Jeff Hardy]

Hi,
I'm wondering if there's anyone out there willing to help update the
website, in particular replacing the big "IronPython Tools" banner
with something else. Updating it isn't too hard and I'll offer any
assistance that may be necessary.

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

Re: [IronPython] Moving forward on 2.7.1

[Jeff Hardy]

On Fri, Jun 10, 2011 at 8:02 AM, Zachary Gramana
 wrote:
> There are some big Python applications (e.g. Mercurial) that are going to
> remain on 2.7 for some time. There are important modules that are still
> missing (bz2), or are incomplete (_winreg), that create compatibility
> barriers.  It would also be nice to have sockets moved to the
> socket.py/_socket.cs model (similar to how ssl has been implemented) to
> support apps that monkey patch that module.

100% agreed. I don't want to see 2.7 whither, for exactly the reasons
you mention, and there is still a lot of low hanging fruit that could
make it much better. The thing is, my own interests are drifting to
Python 3, because I think it will allow IronPython to be as close to
perfectly compatible as possible. Plus, it will give me a chance to
really get into the guts of IronPython, which I'm going to document
more fully as I go.

>
> I know the community is limited in resources, but I would hope that 2.7 not
> be abandoned too quickly. I would happily volunteer to own the maintenance
> of 2.7, but I am far too early in the learning curve to be of any practical
> use.  That said, I'm happy to help on items where I am familiar with that
> part of the codebase, or where an experienced contributor can give me some
> mentoring. For example, I'm interested in helping to implement the bz2
> module using ic#code's #zip lib
> (http://www.icsharpcode.net/OpenSource/SharpZipLib/), but would definitely
> need some mentoring along the way.

I will do (almost) whatever I need to to get more people involved in
this project. Unimplemented or incomplete modules are a great place to
start (that's how I started). Any assistance (no matter how small) is
appreciated.

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

Re: [IronPython] differences in IronPython/CPython regular expressions?

[Jeff Hardy]

On Thu, Jun 2, 2011 at 11:58 AM, Bill Janssen  wrote:
> Would gdb work?  I'll try.

Mono's debugger might be better, if their regex engine is managed. It
looks like there's some Mono support in gdb but I've never used it.

On Windows, windbg is your friend. It's about as user-friendly as gdb,
though (take that how you want).

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

Re: [IronPython] differences in IronPython/CPython regular expressions?

[Jeff Hardy]

On Thu, Jun 2, 2011 at 9:41 AM, Bill Janssen  wrote:
> Jeff Hardy  wrote:
>
>> The fact that it works on CPython fairly fast indicates a bug
>> somewhere, I'm just not sure if it's IronPython or Mono.
>
> I just tried it with real MS .NET, on a 64-bit Windows 7 machine with a
> new download of IronPython 2.7.  On that platform, it core-dumps (well,
> ipy exits with a StackOverflowException).

Any chance you could get a debugger on there and figure out where the
SOE is (IronPython or .NET)? If not, I can try to take a look if you
send the complete regex, but probably not until the weekend.

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

Re: [IronPython] differences in IronPython/CPython regular expressions?

[Jeff Hardy]

> Sure.  Names sensitive to capitalization; the rule I'm implementing says
> names are either capitalized or upper-case.

Ah, I see that now. I assumed the name lists were in lower case.

>
>> For the most part, CPython and IronPython regexes should be fairly
>> compatible - IronPython takes the regex and massages it to work with
>> System.Text.RE, but the changes are pretty straightforward and small,
>
> Are those changes documented anywhere?

The code is in Languages\IronPython\IronPython.Modules\re.cs in the
PreParseRegex function; it's pretty straightforward, if a little long.
Looking at it again, it's quite possible there's a bug in there, but
we'd need a minimal repro to have any hope of finding it.

> No need, until I hit .NET.  I'm used to working with a full-featured
> finite-state machine (PARC's xfst; see
> http://www.cis.upenn.edu/~cis639/docs/xfst.html), and was wondering if
> we could do similar things with Python's RE machinery.  Long lists like
> these names are often used for lists of companies or cities or such.
> People's names are actually a fairly simple and short example of this :-).

The fact that it works on CPython fairly fast indicates a bug
somewhere, I'm just not sure if it's IronPython or Mono.

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

Re: [IronPython] differences in IronPython/CPython regular expressions?

[Jeff Hardy]

On Wed, Jun 1, 2011 at 4:03 PM, Bill Janssen  wrote:
> I have a large RE (223613 chars) that works fine in CPython 2.6, but

That's truly horrible, but I assume you have a good reason for it.

> seems to produce an endless loop in IronPython (see below).  I'm using
> Mono 2.10 (.NET 4.0.x) on Ubuntu, with IronPython 2.7.  Anyone have
> pointers to the differences between them?  Is
> System::Text::RegularExpressions in .NET configurable in some fashion
> that might help?

First off, is there a reason you don't use re.IGNORECASE? That would
cut the regex in half, at least.

For the most part, CPython and IronPython regexes should be fairly
compatible - IronPython takes the regex and massages it to work with
System.Text.RE, but the changes are pretty straightforward and small,
and I don't think the re you provided hits any of them. It's quite
possible that the Mono version of System.Text.RE can't handle the
expression; you could test this saving the full regex and building a
small C# program that runs it. The regex template has a lot of
potential backtracking in it; are you sure it's not caught in a
pathological (exponential) case?

Finally, is one ginormous really the best way to do this? Have you
tried other approaches?

- Jeff

>
> I'm a .NET newbie.
>
> TIA,
>
> Bill
>
> --
> import sys, os, re
>
> try:
>    # we use the name lists in nltk to create person-name matching patterns
>    import nltk.data
> except ImportError:
>    sys.stderr.write("Can't import nltk; can't do name lists.\nSee 
> http://www.nltk.org/.\n";)
>    sys.exit(1)
> else:
>    __MALE_NAME_EXCLUDES = ("Hill",
>                          "Ave",
>                          )
>    __FEMALE_NAME_EXCLUDES = ()
>    __FEMALE_NAMES = [x for x in
>                      nltk.data.load("corpora/names/female.txt", 
> format="raw").split("\n")
>                      if (x and (x not in __FEMALE_NAME_EXCLUDES))]
>    __FEMALE_NAMES += [x.upper() for x in __FEMALE_NAMES]
>    __MALE_NAMES = [x for x in
>                    nltk.data.load("corpora/names/male.txt", 
> format="raw").split("\n")
>                    if (x and (x not in __MALE_NAME_EXCLUDES))]
>    __MALE_NAMES += [x.upper() for x in __MALE_NAMES]
>    __INITS = [chr(x) for x in range(ord('A'), ord('Z'))]
>
> PERSON_PATTERN = re.compile(
>    "^((?PMr|Ms|Mrs|Dr|MR|MS|MRS|DR)\.? )?"         # honorific
>    "(?P" +
>    "|".join(__FEMALE_NAMES + __MALE_NAMES + __INITS) + # first name
>    ")"
>    "( (?P([A-Z]\.)|(" +
>    "|".join(__FEMALE_NAMES + __MALE_NAMES) +         # middle initial or name
>    ")))?"
>    " +(?P[A-Z][A-Za-z]+)",             # space then last name
>    re.MULTILINE)
>
> print PERSON_PATTERN.match("Mr. John Smith")
> ___
> 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

Re: [IronPython] memoryview

[Jeff Hardy]

On Wed, Jun 1, 2011 at 2:50 PM, Peter Schwalm  wrote:
> In the moment, I can only hope that no information is lost during the
> implicit conversions of file i-o. That means I hope these conversion simply
> add a 0-byte to every byte read in to make it unicode and only discards the
> 0-byte when writing to a file.

I'm 99% sure that's how it works.

One other option that I forgot about is the 2.7 io module:

f = io.open('data.txt', 'rb')
b = f.read()

Passing the 'b' flag to open causes it to return bytes instead of
strings, which should give you what you want.

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

Re: [IronPython] memoryview / passing string data to a C functionwithout copying

[Jeff Hardy]

On Tue, May 31, 2011 at 11:01 PM, Markus Schaber
 wrote:
> Hi, Peter,
>
>> Von: users-boun...@lists.ironpython.com [mailto:users-
> [...]
>>
>>      Does anyone know how to pass the contents of a string to a C
> function
>> without copying it?
>
> A non-pythonic suggestion:
>
> Maybe you could use the .NET System.FileStream to read the data into a
> byte array (or a .NET memory stream), and pass that one to the cFunc?

This is probably your best bet. file() doesn't return bytes until Python 3.

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

[IronPython] Moving forward on 2.7.1

[Jeff Hardy]

Hi all,
I think it's about time to get 2.7.1 shipped. I don't have a timeline
in mind, but I'd like it out by the end of June. There's a few new
modules and some bug fixes as well, but I'd like to see some more bugs
fixed. If there's anything in 2.7.0 that's blocking you and not
already fixed, post it here and I'll adjust the priorities. I'm also
going to update the stdlib to match CPython 2.7.1.

After 2.7.1 I doubt I will be putting much effort into the 2.7 branch
(3.0 is just more interesting), so if there's continued interest in
future 2.7 releases, someone else will probably have to step up.

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

Re: [IronPython] clr.ImportExtensions are not available outside module ?

[Jeff Hardy]

On Fri, May 13, 2011 at 5:41 AM, daniel kottow  wrote:
> What I was trying to say that, unfortunately, I do not see a way to 
> encapsulate
> my extension methods written in C# so that a person doing only python does not
> have to worry about it -
> on the other hand, i reckon it is also not such a big deal to write some
> clr.ImportExtensions on the beginning of a module and then the developer *can*
> forget on how the methods got there.

Don't forget that Python is a dynamic language - you can add methods
to the class after it's defined. You might have to inherit from the
.NET class in Python, but then you can loop over the extension methods
and add them to the Python class.

It might be nice to have a clr.ImbueTypeWithExtensions(cls, extcls)
method that did this, and made the extensions available everywhere,
but it would have to be used with care.

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

Re: [IronPython] Python Tools for Visual Studio now accepting contributions

[Jeff Hardy]

The IronPython Tools (or "old" tools) are the original VS integration
tools, developed when IronPython was still funded by MS. PTVS is a new
set of Python (not IronPython-specific; they support CPython and
IronPython, and some Jython and PyPy) tools Dino's working on for MS's
Technical Computing group. Some of the features are HPC-specific (like
MPI cluster debugging) but for the most part it's just a nice Python
environment, and a lot more stable than the old tools.

Dino, can the HPC stuff be split out for people who don't need it?

PTVS is significantly better then the old tools and is also under
active development, and now that they're accepting contributions it
makes sense to me to retire the old tools and just get people to
download PTVS (I doubt we'll bundle them, but instead have a big link
next on the download page).

- Jeff

On Wed, May 11, 2011 at 1:27 PM, Keith Rome  wrote:
> Please forgive my ignorance on this matter (I don't currently use any of the 
> integrated VS functionality - have been working with embedding the runtime in 
> an existing application), but what is the difference between "IronPython 
> Tools" and "Python Tools for Visual Studio"? I was under the impression this 
> was the same thing?
>
>
> Keith Rome
> Senior Consultant and Architect
> MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
> Wintellect | 770.617.4016 | kr...@wintellect.com
> www.wintellect.com
>
> -Original Message-
> From: users-boun...@lists.ironpython.com 
> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Wednesday, May 11, 2011 4:26 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Python Tools for Visual Studio now accepting 
> contributions
>
>
>
> Jeff wrote:
>> This is excellent news.
>>
>> I think the plan should now be to deprecate the IronPython tools and
>> remove them from IronPython 3.0. They'll stay in future 2.7 releases,
>> but perhaps they should be disabled by default to make installing PTVS 
>> easier?
>
> That sounds like a good idea to me and it should be a pretty simple change.
>
>
> ___
> 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
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Python Tools for Visual Studio now accepting contributions

[Jeff Hardy]

This is excellent news.

I think the plan should now be to deprecate the IronPython tools and
remove them from IronPython 3.0. They'll stay in future 2.7 releases,
but perhaps they should be disabled by default to make installing PTVS
easier?

- Jeff

On Wed, May 11, 2011 at 1:13 PM, Dino Viehland  wrote:
> We’ve been in a difficult place with having two sets of tools for Visual
> Studio that both work with IronPython.  Those are the existing IronPython
> Tools that shipped w/ 2.7 and the newer Python Tools for Visual Studio which
> are derived from the original IronPython code base.  To make things more
> difficult we’ve been living in a world where you could contribute back to
> IronPython Tools but contributions weren’t being accepted back to PTVS.
> That’s obviously not the best environment for encouraging users to submit
> changes back and today I’m happy to announce that we’ve fixed this problem
> and we’re now accepting contributions back to PTVS!
>
>
>
> If you’re interested in contributing back feel free to fork PTVS
> (http://pytools.codeplex.com/SourceControl/network) and submit a pull
> request for your changes.  Basic contribution guidelines are available here:
> http://pytools.codeplex.com/wikipage?title=Contributing%20to%20PTVS&version=1
> and instructions for getting setup to build are available here:
> http://pytools.codeplex.com/wikipage?title=Build%20Instructions%20for%20PTVS
>
>
>
>
>
> ___
> 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

Re: [IronPython] GetRunningObjectTable

[Jeff Hardy]

GetRunningObjectTable isn't a static method, so you'll need to call it
on an instance of IBindCtx. Not sure where you'd get one of those,
though.

- Jeff

On Wed, Apr 27, 2011 at 1:40 PM, Sébastien de Menten
 wrote:
> Hi,
>
> I am trying to use the GetRunningObjectTable function to retrieve a list of
> all running objects (to later use them in COM automation).
>
> I do the following :
>
 import System

 System.Runtime.InteropServices.ComTypes.IBindCtx.GetRunningObjectTable(0)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: expected IBindCtx, got int
>
> I am puzzled by the error as, if i understood properly the way ipy works, I
> would expect to give an Int as input parameter and get back a tuple with the
> restult of the function and the out parameter.
>
> If i replace the 0 with a refernce to a IBindCtx type:
 import clr
 rot=clr.Reference[System.Runtime.InteropServices.ComTypes.IBindCtx]()

 System.Runtime.InteropServices.ComTypes.IBindCtx.GetRunningObjectTable(rot)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: expected IBindCtx, got StrongBox[IBindCtx]
>
> My knowledge of .net is quite reduced ... any help would be greatly
> appreciated
>
> sebastien
>
> ps: sorry if this message appears as reposted but I do not see it in the
> mailing list after more than 24 hours ...
>
> ___
> 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

Re: [IronPython] need help to build Ironpython

[Jeff Hardy]

I checked in a commit that does that (see the last commit), but i
didn't delete the rest of the source.

- Jeff

On Thursday, April 21, 2011, Jimmy Schementi  wrote:
> Just for clarity, here's the URL:http://github.com/IronLanguages/main
> We should remove the source from CodePlex with a readme that redirects people 
> to github.
>
> ~Jimmy
> On Apr 21, 2011, at 11:08 PM, Slide  wrote:
>
> The source on codeplex is old. Check out github repo ironlanguages. That is 
> where the source currently resides.
> On Apr 21, 2011 7:29 PM, "surangika ranathunga"  
> wrote:> Hi All,
>> I have downloaded Ironpython source code using subversion, from the url 
>> https://IronPython.svn.codeplex.com/svn (hope this is a stable version to 
>> build ironpython dlls to be used in other projects).
>>
>> Then I located IronPython.sln inside IronPython_Main\Solutions folder and 
>> opened this in VS, and ran the build command. The build was successful and 
>> now I have the new dll files.
>> Is this how the building process is done?
>>
>>
>
> ___
> 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

Re: [IronPython] how to generate multiple concurrent scriptign engines?

[Jeff Hardy]

Can one of your alter-egos file a bug so it doesn't get lost?

- Jeff

On Fri, Apr 15, 2011 at 10:36 AM, Dino Viehland  wrote:

>  It might come from CopyReg but the bug is definitely in GetEqualSite – we
> just need a lock(_equalSites) { … } around the TryGetValue and creation of
> the equal site.
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Jeff Hardy
> *Sent:* Friday, April 15, 2011 7:29 AM
> *To:* surangika ranathunga
> *Cc:* Discussion of IronPython
>
> *Subject:* Re: [IronPython] how to generate multiple concurrent scriptign
> engines?
>
>
>
> Any chance you can share what the source is? The exception comes from
> PythonCopyReg's initialization, which means we might have a bug (it might
> not be thread-safe, or something else). If you could create a minimal sample
> that has the issue that would be even better.
>
>
>
> - Jeff
>
> On Thu, Apr 14, 2011 at 9:18 PM, surangika ranathunga <
> lady_ra...@yahoo.com> wrote:
>
> Hi,
> Below is the exception I receive:
> here, D:\PhD
> Work\Research\libomv\test\MonitorService\MonitorService\ExpectationMonitor.cs:line
> 88 refers to source.Execute(scope); in the below given code.
>
> System.Reflection.TargetInvocationException: Exception has been thrown by
> the target of an invocation. --->
> System.Reflection.TargetInvocationException: Exception has been thrown by
> the target of an invocation. ---> System.NullReferenceExce
> ption: Object reference not set to an instance of an object.
>at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue
> value, Boolean add)
>at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue
> value)
>at IronPython.Runtime.PythonContext.GetEqualSite(Type type)
>at IronPython.Runtime.CommonDictionaryStorage.UpdateHelperFunctions(Type
> t, Object key)
>at IronPython.Runtime.CommonDictionaryStorage.AddNoLock(Object key,
> Object value)
>at IronPython.Runtime.CommonDictionaryStorage.Add(Object key, Object
> value)
>at IronPython.Runtime.PythonDictionary.SetItem(Object key, Object value)
>at IronPython.Runtime.PythonDictionary.set_Item(Object key, Object
> value)
>at IronPython.Modules.PythonCopyReg.PerformModuleReload(PythonContext
> context, PythonDictionary dict)
>--- End of inner exception stack trace ---
>at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
> method, Object target, Object[] arguments, SignatureStruct& sig,
> MethodAttributes methodAttributes, RuntimeType typeOwner)
>at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
> method, Object target, Object[] arguments, Signature sig, MethodAttributes
> methodAttributes, RuntimeType typeOwner)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
> skipVisibilityChecks)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
>at IronPython.Runtime.PythonContext.CreateBuiltinModule(String
> moduleName, Type type, ModuleOptions options)
>at IronPython.Runtime.PythonContext.CreateBuiltinModule(String
> moduleName, Type type)
>at IronPython.Runtime.PythonContext.CreateBuiltinModule(String name)
>at IronPython.Runtime.PythonContext.GetBuiltinModule(String name)
>at IronPython.Runtime.Importer.ImportBuiltin(CodeContext context, String
> name)
>at IronPython.Modules.PythonCopyReg.EnsureModuleInitialized(CodeContext
> context)
>at IronPython.Modules.PythonCopyReg.GetDispatchTable(CodeContext
> context)
>at IronPython.Modules.PythonRegex.PerformModuleReload(PythonContext
> context,PythonDictionary dict)
>--- End of inner exception stack trace ---
>at
> Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] args,
> Boolean& shouldOptimize)
>at
> IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite
> site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3
> arg3)
>at
> System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite
> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
>at IronPython.Runtime.Importer.Import(CodeContext context, String
> fullName, PythonTuple from, Int32 level)
>at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
> context, String fullName, Int32 level)
>at
> Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(Interpre

Re: [IronPython] how to generate multiple concurrent scriptign engines?

[Jeff Hardy]

Any chance you can share what the source is? The exception comes from
PythonCopyReg's initialization, which means we might have a bug (it might
not be thread-safe, or something else). If you could create a minimal sample
that has the issue that would be even better.

- Jeff

On Thu, Apr 14, 2011 at 9:18 PM, surangika ranathunga
wrote:

> Hi,
> Below is the exception I receive:
> here, D:\PhD
> Work\Research\libomv\test\MonitorService\MonitorService\ExpectationMonitor.cs:line
> 88 refers to source.Execute(scope); in the below given code.
>
> System.Reflection.TargetInvocationException: Exception has been thrown by
> the target of an invocation. --->
> System.Reflection.TargetInvocationException: Exception has been thrown by
> the target of an invocation. ---> System.NullReferenceExce
> ption: Object reference not set to an instance of an object.
>at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue
> value, Boolean add)
>at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue
> value)
>at IronPython.Runtime.PythonContext.GetEqualSite(Type type)
>at IronPython.Runtime.CommonDictionaryStorage.UpdateHelperFunctions(Type
> t, Object key)
>at IronPython.Runtime.CommonDictionaryStorage.AddNoLock(Object key,
> Object value)
>at IronPython.Runtime.CommonDictionaryStorage.Add(Object key, Object
> value)
>at IronPython.Runtime.PythonDictionary.SetItem(Object key, Object value)
>at IronPython.Runtime.PythonDictionary.set_Item(Object key, Object
> value)
>at IronPython.Modules.PythonCopyReg.PerformModuleReload(PythonContext
> context, PythonDictionary dict)
>--- End of inner exception stack trace ---
>at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
> method, Object target, Object[] arguments, SignatureStruct& sig,
> MethodAttributes methodAttributes, RuntimeType typeOwner)
>at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
> method, Object target, Object[] arguments, Signature sig, MethodAttributes
> methodAttributes, RuntimeType typeOwner)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
> skipVisibilityChecks)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
>at IronPython.Runtime.PythonContext.CreateBuiltinModule(String
> moduleName, Type type, ModuleOptions options)
>at IronPython.Runtime.PythonContext.CreateBuiltinModule(String
> moduleName, Type type)
>at IronPython.Runtime.PythonContext.CreateBuiltinModule(String name)
>at IronPython.Runtime.PythonContext.GetBuiltinModule(String name)
>at IronPython.Runtime.Importer.ImportBuiltin(CodeContext context, String
> name)
>at IronPython.Modules.PythonCopyReg.EnsureModuleInitialized(CodeContext
> context)
>at IronPython.Modules.PythonCopyReg.GetDispatchTable(CodeContext
> context)
>at IronPython.Modules.PythonRegex.PerformModuleReload(PythonContext
> context,PythonDictionary dict)
>--- End of inner exception stack trace ---
>at
> Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] args,
> Boolean& shouldOptimize)
>at
> IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite
> site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3
> arg3)
>at
> System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite
> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
>at IronPython.Runtime.Importer.Import(CodeContext context, String
> fullName, PythonTuple from, Int32 level)
>at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
> context, String fullName, Int32 level)
>at
> Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame
> frame)
>at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
> frame)
>at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0,
> T1 arg1)
>at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)
>at IronPython.Compiler.PythonScriptCode.Run(Scope scope)
>at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
>at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
>at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink
> errorSink)
>at Microsoft.Scripting.SourceUnit.Execute(Scope scope)
>    at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope)
>at MonitorService.ExpectationMonitor.Initialize(String rule) i

Re: [IronPython] IronPython for Silverlight 5?

[Jeff Hardy]

On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland  wrote:
> Jeff wrote:
>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
>> wrote:
>> > I see Silverlight 5 now has something besides simple reflection
>> > (ICustomTypeProvider) -
>> >
>> > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>> >
>> > Will we see an update to Iron*/DLR to support binding to dynamic
>> > objects any time soon? This will open fantastic options for using
>> > IronPython in Silverlight.
>>
>> If someone provides a patch, yes.
>>
>> We actually need someone with an interest in Silverlight to keep an eye on it
>> and make sure that we don't break SL support and new features like this. We
>> don't have anyone in that role right now.
>
> If anyone's interested on working on this it'd probably mean adding an 
> implementation
> of this onto OldInstance as well as adding it onto our new-style instances 
> whose
> classes are created by NewTypeMaker.  Adding the interface is probably pretty 
> easy,
> making it return useful things may be a little more difficult.
>
> I'm a little surprised they didn't go with the already existing 
> ICustomTypeDescriptor.

Are you really surprised? :)

It is still in Beta. Maybe there's a slight chance their minds could
be changed? I'm guessing they don't have the rest of
System.ComponentModel either, so they didn't want to add just one
interface.

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

Re: [IronPython] how to generate multiple concurrent scriptign engines?

[Jeff Hardy]

As long as you have a ScriptScope per thread, you should be able to
share the ScriptEngine & Runtime between threads.

What is the exception that you are getting? If it's a GUI program,
remember that UI elements can only be manipulated from the main
thread.

- Jeff

On Thu, Apr 14, 2011 at 1:02 AM, surangika ranathunga
 wrote:
>
> Hi,
> I am using Ironpython to connect to a legacy python code from C#.
> I am not fully familiar with Ironpython, but managed to get it working for a 
> single-threaded application.
> This is how I implemented this:
>
>     ScriptEngine engine = Python.CreateEngine();
>     ScriptRuntime runtime = engine.Runtime;
>     ScriptScope scope = runtime.CreateScope();
>     ops = engine.Operations;
>     ScriptSource source = 
> engine.CreateScriptSourceFromFile("ironpython.py");
>     source.Execute(scope);
>     string class_param = rule;
>     object[] parameters = new object[1];
>     parameters[0] = class_param;
>     object klass = scope.GetVariable("model_checker");
>     object instance = ops.Invoke(klass, parameters);
>     method = ops.GetMember(instance, "check_model");
>
> Now I want to make my application multi-threaded, and I want to have 
> concurrently running scripting engines. Essentially, these engines should 
> access the same underlying python code, and hence these scripting engines are 
> identical to each other.
> Without any change, the above code works fine for most of the time for a 
> multi-threaded application. However, there is an exception that appears from 
> time to time, and I suspect that it is due to a concurrency issue.
>
> Is there anything specific that I should do to generate multiple scripting 
> engines running in separate threads without interfering with each other?
>
> any ideas greatly appreciated
>
> ___
> 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

Re: [IronPython] IronPython for Silverlight 5?

[Jeff Hardy]

On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman  wrote:
> I see Silverlight 5 now has something besides simple reflection
> (ICustomTypeProvider) -
>
> http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>
> Will we see an update to Iron*/DLR to support binding to dynamic objects any
> time soon? This will open fantastic options for using IronPython in
> Silverlight.

If someone provides a patch, yes.

We actually need someone with an interest in Silverlight to keep an
eye on it and make sure that we don't break SL support and new
features like this. We don't have anyone in that role right now.

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

Re: [IronPython] Fwd: IronPython and Mono are very old. How can we get an update?

[Jeff Hardy]

Vernon, thank you very much for handling this!

On Thu, Apr 7, 2011 at 7:26 PM, Vernon Cole  wrote:
> This may still be a sticky spot.  The tarball does contain IronRuby, but
> what version?

Should be 1.1.3.

> There must be a version identifier somewhere, but it is not obvious. The
> only Ruby version number I found when hunting around this afternoon was in
> an .html file, and the version number was 0.1!   I'm pretty sure that is
> wrong.

Look for "IronRubyInformationalVersion" in
Languages\Ruby\Ruby\Runtime\RubyContext.cs. But yes, it should be in
the README (and the README should be fleshed out quite a bit, given
that github shows it on the first page).


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

[IronPython] Google Summer of Code

[Jeff Hardy]

Hi,
If anyone is still interested in doing an IronPython, IronRuby, or any
other DLR-related project for GSoC, feel free to submit them to either
the Mono project (IronPython/IronRuby/DLR) or the Python Software
Foundation (IronPython). The deadline is tomorrow (Friday, April 8 at
19:00 UTC), so you'll have to act quickly.

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

Re: [IronPython] IronPython and XML Parsing

[Jeff Hardy]

On Wed, Apr 6, 2011 at 12:14 PM, Doug Blank  wrote:
> Why can't we have a IPy 2.7 for .NET 2.0? It builds nicely, now, and
> should be fine as a drop-in replacement for what ubuntu (and others)
> were packaging before.

Someone else will have to volunteer to maintain it. I'm hoping to make
some changes to the CI server (which does 2.0 builds now as well, to
make sure that it still compiles) to properly generate nightly zip
builds; would that be enough?

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

Re: [IronPython] IronPython and XML Parsing

[Jeff Hardy]

On Wed, Apr 6, 2011 at 11:07 AM, Vernon Cole  wrote:
> I have sent several emails to Seo asking him about the status of fepy,
> and received no response.  I think this would be a great place to
> build a "fatter" distribution of IronPython, with more modules
> attached, and a set of Linux binaries.  (Besides, I hate having my
> name associated with a dead project - Mike Foord and Jeff too, I would
> suppose.)

Linux-specific binaries shouldn't be needed anymore - they should work
out of the box on Mono (although if you want to maintain the .NET
2.0/IronPython 2.7 builds, that might be useful). As for libraries, I
would like to see the packaging tools like pip working on IronPython
so you could just do `ipip install fepy` and get the bonus modules.

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

Re: [IronPython] IronPython and XML Parsing

[Jeff Hardy]

On Wed, Apr 6, 2011 at 2:38 AM, Markus Schaber
 wrote:
> Has anyone successfully tried this implementation? What about including
> it into the IronPython distribution?

The fepy version is incomplete, but it mostly works. I haven't run the
tests in a while, though, so I'm not sure how incomplete it is. I'm
also unsure if we can get 100% compatibility using System.Xml; much
like sqlite, it may have to p/invoke the C expat lib for perfect
combatibility.

pyexpat is one of the last builtin modules not included (I should be
able to land _ast this weekend and unicodedata "soon"). If anyone
sends a pull request with the majority of the tests passing, I'd be
very happy to include it.

> PS: Is FePy still alive at all? The last commit seems to be from July
> 2009...

I don't think so.

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

Re: [IronPython] [Code Review] Custom PAL fixes

[Jeff Hardy]

On Thu, Mar 31, 2011 at 7:05 PM, Jimmy Schementi  wrote:
> Just checked in some small fixes to make the Importer use a custom Platform
> Adaptation Layer. I also started to tweak clr.CompileModules a bit, but
> backed those changes out, so just ignore those.
> Take a look at the recent commits to https://github.com/jschementi/iron. If
> there are no objections, I'll push them to main.

If Dino's happy, that's good enough for me.

Should these changes be in the 2.7 branch as well, or just master
(3.0)? It doesn't look like there are any API changes, so applying it
to 2.7 should be fine.

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

Re: [IronPython] Debugging hosted python scripts

[Jeff Hardy]

On Wed, Mar 30, 2011 at 8:52 PM, Keith Rome  wrote:
> We currently have a line of business application, written entirely in C#,
> that embeds the IronPython runtime. We offer a GUI script editing
> environment (using the SyntaxEditor control from Actipro Software, which
> works great for this). This script editor exists as just another dialog
> window in our application where the user can extend the business objects
> behind the application in various ways. The scripts are stored in a
> database, not in files on the local file system. We have great support for
> syntax highlighting, compiler error “squiggles”, even Intelliprompt
> functionality. I am now building live debugging support into our script
> editor GUI, which is where I have run into some difficulty.
>
>
>
> I have been going down the path of using ScriptEngine.SetTrace() and
> inspecting frames in the callback. This works fine if I am not doing
> anything interactive. For example, dumping some information to
> Debug.WriteLine(). However what I really need (I think?) is to be able to
> suspend the script execution during a trace callback. I don’t see a clear
> way to do this though. The script runtime simply continues execution when my
> callback returns. I have done some work around running the debugged script
> on a background thread, and then blocking it during “breakpoint” callbacks –
> but these scripts are normally run within the UI thread because they
> interact with data structures that are often databound to UI controls, and
> running them from a background thread is becoming a minefield of
> cross-thread violations. I cannot simply run the script in the UI thread,
> because blocking in the trace callback would make the application
> unresponsive.

I think this is going to be your biggest issue with debugging - AFAIK
the Python engine is not designed to be suspendable; it relies on
.NET's normal thread suspension mechanism to handle that case. If the
scripts are on the UI thread, and the debugger is on the UI thread,
that 's going to be an issue.

Now, if the engine were running in interpreted mode (i.e. it doesn't
try to convert Python to IL), it would probably be possible to suspend
it without suspending the thread, but I have no idea how much work
that would be. (Heck, it might already support it - Dino?) My hunch is
that it wouldn't be a huge amount of work, but I'm not familiar with
the interpreter loop at all.

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

Re: [IronPython] IronPython Tools for VS2010 Questions

[Jeff Hardy]

On Wed, Mar 30, 2011 at 9:12 AM, Bill Dines  wrote:
> 3. Is anyone currently working on the IPy tools specifically?  There are
> quite a lot of bugs right now unfortunately and many of them would need
> to be fixed if we were to use it.  Note that my company may be willing
> to provide some resource in that area if we decide to proceed, but we
> don't have much experience with VS extensions so we may need some
> guidance.

Addressing this specifically - Microsoft is maintaining their own
Python Tools for Visual Studio ("new" tools), which is a descendant of
IronPython Tools ("old" tools). The new tools support CPython as well
as IronPython and are being developed by full-time staff at MS (Dino
V, who wrote the original IronPython tools).

This puts the future of the old tools in a tough spot, since any work
on them would be a duplicate of the new tools. If the legal beagles at
MS can be convinced to allow them to take contributions back into
Python Tools (the source is available, but like IronPython of old,
they can't accept outside code), then the old tools will get critical
updates, but I'll point people at the new tools for production work.

Take a look at the new tools (http://pytools.codeplex.com/) and see if
they're a better fit for what you're trying to do.

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

Re: [IronPython] Transparent import of dlls?

[Jeff Hardy]

On Tue, Mar 29, 2011 at 4:30 AM, Markus Schaber
 wrote:
> For IronPython, there is the pyc.py compiler script. This allows a python
> module to be precompiled into a .NET dll. However, it seems that it is not
> used transparently when placed in a directory in sys.path, one has to
> explicitly add a Reference to the dll (via clr.AddReference or hosting API).
>

That, currently, is the only way to do it.

> We’re currently using IronPytho 2.6 in a hosted .NET 2 environment.

For ipy.exe, there's a special directory called 'DLLs' that it reads
on startup and does the hosting equivalent of clr.AddReference for
each .dll in the folder. That's about the best you can do right now.

I've been thinking of adding support for .ipyd files (similar to
Python .pyd files), which could handle this case, but haven't thought
it through yet.

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

Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!

[Jeff Hardy]

On Fri, Mar 25, 2011 at 12:46 PM, Doug Blank  wrote:
> Excellent! IronPython 3.0 (trunk) with .NET framework 2.0 *builds* and
> *runs* great under Mono 2.10. And it seems to *run* great under Mono
> 2.6.7 as well! It does NOT build under Mono 2.6.7, but I suspect that
> many mono build issues between 2.6.7 and 2.10 have been fixed.

When I get a chance I'll cherry-pick those changes onto the
ipy-2.7-maint branch as well. There's not much difference now, but
they will diverge quite a bit in the future.

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

Re: [IronPython] IronPython2.7 import locking error

[Jeff Hardy]

On Fri, Mar 25, 2011 at 12:14 PM, Dino Viehland  wrote:
> It looks like the CRT implements this by calling the LockFile/UnlockFile 
> Win32 APIs (potentially retrying w/ 1 second between tries depending on the 
> mode) so we could do that ourselves w/ the OS file handles.

Clever. Note to self: FileStream.SafeFileHandle.

- Jeff

>
> -Original Message-----
> From: Jeff Hardy [mailto:jdha...@gmail.com]
> Sent: Friday, March 25, 2011 11:08 AM
> To: Discussion of IronPython
> Cc: Dino Viehland
> Subject: Re: [IronPython] IronPython2.7 import locking error
>
> On Thu, Mar 24, 2011 at 6:41 PM, Dino Viehland  wrote:
>> Oh I see I missed the line containing msvcrt.  This just looks like it 
>> hasn't been implemented (we still have only a very partially implemented 
>> version of msvcrt).  It should be trivial to do add this , it should just be 
>> a P/Invoke out to msvcrt100, if someone wants to provide a patch.
>
> It seems to me that msvcrt.locking is actually quite tricky, as it normally 
> uses the CRT file handles when calling the locking functions.
> We'd have to emulate the behavior using the .NET locking functions (or 
> rewrite all of our file APIs to use the CRT).
>
> - Jeff
>
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython2.7 import locking error

[Jeff Hardy]

On Thu, Mar 24, 2011 at 6:41 PM, Dino Viehland  wrote:
> Oh I see I missed the line containing msvcrt.  This just looks like it hasn't 
> been implemented (we still have only a very partially implemented version of 
> msvcrt).  It should be trivial to do add this , it should just be a P/Invoke 
> out to msvcrt100, if someone wants to provide a patch.

It seems to me that msvcrt.locking is actually quite tricky, as it
normally uses the CRT file handles when calling the locking functions.
We'd have to emulate the behavior using the .NET locking functions (or
rewrite all of our file APIs to use the CRT).

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

Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!

[Jeff Hardy]

On Wed, Mar 23, 2011 at 7:13 AM, Doug Blank  wrote:
> Questions:
>
> 1) How to build a Release version rather than Debug?
> 2) How to set the framework to use 2.0 rather than 4.0?

1) msbuild Solutions/Dlr.sln /p:Configuration="Release"
2) msbuild Solutions/Dlr.sln /p:Configuration="v2Debug" (or "v2Release")

I assume xbuild's command line matches msbuild's.

However, it appears that building the "v2..." targets doesn't work
right now, which I was kinda afraid of. I think there's a discrepancy
between the Microsoft.Scripting DLR and the .NET 4 DLR.

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

Re: [IronPython] multiprocessing in 2.7

[Jeff Hardy]

On Wed, Mar 23, 2011 at 7:19 AM, Romain Gilles  wrote:
>  but who can I add to my IronPython the _multiprocessing module ?
> --
> c:\temp>ipy test-ipy-multiprocessing.py
> Traceback (most recent call last):
>   File "test-ipy-multiprocessing.py", line 1, in 
>   File "c:\Program Files\IronPython
> 2.7\lib\site-packages\multiprocessing\__init__.py", line 83, in 
> ImportError: No module named _multiprocessing
> --
> Maybe It cannot be resolved that way.

Unfortunately, no one has written an IronPython version of
_multiprocessing, so it's not supported. It's probably one of the
trickiest remaining modules to support, so contributions are welcome,
as always.

- Jeff

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

Re: [IronPython] Building IronPython/IronRuby for Mono?

[Jeff Hardy]

On Tue, Mar 22, 2011 at 11:03 AM, Doug Blank  wrote:
> I'm not too concerned about ipy.exe itself, but about being about to
> use the dlls.
>
> I'm trying to verify that the IronPython 2.7 dlls absolutely need Mono
> 2.8 or later. If that is true, I'll have to stay with IronPython 2.6
> until the rest of the Linux distros catch up (or I make my own version
> of Mono to download). Perhaps Miguel or someone from SuSE can add more
> details to the dependencies for building and running IronPython 2.7?

IronPython 2.7 *should* build for .NET 2.0, although it's not the
default (I don't remember the name of the MSBuild configuration to do
so, though). However, I don't think that was consistently tested, so I
don't know if it works. I would consider it not working a bug, though.

We won't provide binaries for 2.7/.NET2, but we don't want to prevent
someone building their own either. 3.0, however, will drop support for
.NET 2 entirely.

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

Re: [IronPython] Building IronPython/IronRuby for Mono?

[Jeff Hardy]

On Tue, Mar 22, 2011 at 9:29 AM, Brian Curtin  wrote:
> docs.ironpython.net?
> Might I suggest sphinx-quickstart as the first command to run.

That's kinda what I'm leaning towards, preferably hosted on
readthedocs.com. Most of the docs are already ReST so using sphinx
should be easy. As always, it's just a matter of time, and after
watching Jacob Kaplan-Moss at PyCon, I feel really bad about the state
of our docs right now.

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

Re: [IronPython] Building IronPython/IronRuby for Mono?

[Jeff Hardy]

On Tue, Mar 22, 2011 at 9:19 AM, Doug Blank  wrote:
> Is there a place on IronPython's codeplex site that we could document
> this information?
>
> Currently, there are many assumptions on:
>
> http://ironpython.codeplex.com/wikipage?title=Respository%20Instructions&referringTitle=Home
> http://ironpython.codeplex.com/wikipage?title=Contributing%20to%20IronPython&referringTitle=Home
>
> that suggest that IronPython requires Visual Studio, Windows, etc. I
> guess those wiki pages can't be edited by anyone, but if you make a
> page off of those, I'd be glad to help maintain this alternate build
> and run information. My codeplex id is dsblank.

You now have "Editor" permission and should be able to edit the wiki
to your heart's content. Mono docs would be awesome.

There does need to be a strategy around docs, though. They're really
scattered right now, between codeplex, github, and the source. And
most of them aren't on the websites either. I just don't have a
concrete idea yet about how to deal with that.

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

Re: [IronPython] Building IronPython/IronRuby for Mono?

[Jeff Hardy]

On Tue, Mar 22, 2011 at 6:41 AM, Doug Blank  wrote:
> I went to Codeplex to see about updating Pyjama [1] to use the latest
> IronPython and IronRuby, but had some issues:
>
> 1) There are only two downloads for 2.7: msi and a zip of binaries.
> Shouldn't there be a zip of sources? Or a note how how to get them?

Yes, yes there should. D'oh.

https://github.com/IronLanguages/main/zipball/ipy-2.7

It's fairly big, though, as it's just a package of the git repo. Is
there a ton of value in having smaller zip packages? The download
numbers on them have always been fairly low, so they were dropped for
2.7 in favour of github's automatic zip generation.

> 4) Tried "svn co
> https://IronPython.svn.codeplex.com/svn/IronPython_Main
> IronPython2.7"... but not sure what this is... it has *some* Ruby
> things. How do I build IronRuby and IronPython that use the same DLR
> parts?

The main source is now on https://github.com/ironlanguages/main. I'm
thinking of removing the source tab from CodePlex to avoid confusion,
if that's possible.

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

Re: [IronPython] Building IronPython/IronRuby for Mono?

[Jeff Hardy]

On Tue, Mar 22, 2011 at 7:33 AM, Doug Blank  wrote:
> Is that you need Mono 2.8 to build IronPython, or to run it?
> IronPython2.6 beta 2 is running fine under Mono 2.6.7.

IronPython 2.7 requires .NET 4 (to build and run). Mono 2.10 is
probably your best bet.

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

Re: [IronPython] No GSoC for IronPython/IronRuby for 2011

[Jeff Hardy]

Official announcement:

"Thank you for submitting "IronLanguages" organization application to
Google Summer of Code 2011. Unfortunately, we were unable to accept
your organization's application at this time. We received many more
applications for the program than we are able to accommodate, and we
would encourage you to reapply for future instances of the program.

Best regards,
Google Open Source Programs"

- Jeff

On Mon, Mar 21, 2011 at 1:46 PM, Jonathan Allen
 wrote:
> That really sucks. Did you get that from an announcement or a contact at
> Google?
>
> Jonathan
>
> On Mar 21, 2011 11:50 AM, "Jeff Hardy"  wrote:
>> I got the notice on Friday that IronLanguages was not accepted into
>> Google Summer of Code for 2011. However, both the Mono project and the
>> PSF have indicated that they would consider IronPython/IronRuby
>> projects, so if you're interested, you should ask one of those
>> organizations.
>>
>> - Jeff
>> ___
>> 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
>
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] No GSoC for IronPython/IronRuby for 2011

[Jeff Hardy]

I got the notice on Friday that IronLanguages was not accepted into
Google Summer of Code for 2011. However, both the Mono project and the
PSF have indicated that they would consider IronPython/IronRuby
projects, so if you're interested, you should ask one of those
organizations.

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

Re: [IronPython] Authenticode Signing of Releases

[Jeff Hardy]

Yes, I believe they would - there was a brief discussion at PyCon, but
I haven't made a formal request yet.

- Jeff

On Fri, Mar 18, 2011 at 8:12 AM, Vernon Cole  wrote:
> Resurrecting an old topic...
>
> I just noticed when I loaded a new machine with CPython 2.7, that it
> is signed by the Python Software Foundation.
>
> Do you not suppose that, if asked, they would also be willing to sign
> other implementations?
> --
> Vernon
>
> P.S.: I loaded IronPython 2.7 first!
>
>>> >> On 2/23/2011 10:58 AM, Jeff Hardy wrote:
>>> >>>
>>> >>> Older releases of IronPython were authenticode signed (by Microsoft),
>>> >>> but so far the community releases have not been. As best I can tell,
>>> >>> authenticode certificates are expensive (the cheapest are around
>>> >>> $100/year) - I've heard of deals for open source projects but can't
>>> >>> find anything by searching.
>>> >>>
>>> >>> Is it even worth the hassle to get an authenticode cert for releases?
>>> >>> It adds a bit of extra polish to the installation, but I doubt many
>>> >>> people pay attention to that anyway.
>>> >>>
>>> >>> - Jeff
> ___
> 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

Re: [IronPython] ArenaNet's Use of IronPython

[Jeff Hardy]

On Thu, Mar 17, 2011 at 2:13 AM, Markus Schaber
 wrote:
> Hi,
>
> Is there a wiki page or (semi-)official web page collecting all this usages?

Not yet.


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

Re: [IronPython] Reading from a open excel document

[Jeff Hardy]

On Wed, Mar 16, 2011 at 8:49 AM, Nåjde Henrik  wrote:
> Hello!
>
> I am trying to transfer prameters from an excel sheet to ANSYS Workbench (a
> FEA software), the code is run as a macro in ANSYS workbench.
>
> I have adapted a code that is opening an already existing document and
> successfully transfers parameters from it, so I know that what i want to do
> can be done.
> The problem is that I cant access a already open document and read from it,
> using instructions

Perhaps a silly question, but is that even possible? I'm pretty sure
Excel locks a workbook when it is open, or maybe that's just the
behavior on file shares. (The number of times I've had to unlock
workbooks because someone opened it off a shared drive and then went
for lunch...)

There might be a parameter you can pass when opening the workbook, but
I don't know the Excel object model that well anymore, sorry.

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

Re: [IronPython] IronPython 2.7.1 & 3.x Development

[Jeff Hardy]

On Tue, Mar 15, 2011 at 9:55 AM, Markus Schaber
 wrote:
> As I wrote, we host IronPython inside our application, so shebang and
> file name suffixes are irrelevant - but we could use the shebang as a
> marker for python 3 (given that we can host both versions side-by-side)
> and parse the source manually to find out which version to use - at
> least for a specific grace period.

I think we can support this - it would be no different than using
IronPython and IronRuby side by side, if we do it right. We'd probably
have to rename IronPython.dll to IronPython3.dll as well, but that's
not a big deal.

How you decide which to use would be up to you, though.

Would this be useful for anyone else as well?

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

Re: [IronPython] Rich comparison usage by IronPython's heapq implementation

[Jeff Hardy]

Regardless of what's "correct", we should follow what CPython does
(plus, using only __lt__ and __eq__ makes sense). Can you try this in
2.7 to see if it's still an issue, and open a bug if it is? I doubt
we'll make any more changes to 2.6.

- Jeff

On Mon, Mar 14, 2011 at 6:04 AM, Robert Smallshire
 wrote:
> Hello,
> I recently ran into some issues with IronPython's heapq implementation
> whereby code that functions correctly on CPython failed with IronPython 2.6.
>  The issue is that the CPython implementation of heapq only calls __le__()
> and __eq__() on the heap elements whereas the IronPython implementation
> calls __le__(), __eq__() *and* __gt__().  Although it seems that IronPython
> is well within specification to do so, there are some statements in the
> Python documentation that only __le__() will be used for sorting.  Of
> course, it's arguable whether 'sorting' applies to heapq and indeed other
> similar algorithms or containers which rely on a defined ordering.
> In any case, this is an avoidable difference between CPython and IronPython
> which tripped me up.  I'm not sure whether the correct fix - if one is
> needed at all - is to IronPython's heapq implementation, to CPythons
> documentation, or to both.
> I wrote a little more about the issue here:
>   
> Rob
>
>
>
> ___
> 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

Re: [IronPython] ArenaNet's Use of IronPython

[Jeff Hardy]

That's awesome. I think it might be time to start a "Who's using
IronPython" page somewhere.

The upgrade to 2.7 should be pretty seamless, BTW. Is there anything
that you're missing? Anything that would make your use case easier?

- Jeff

On Mon, Mar 14, 2011 at 3:30 PM, Daniel Jennings  wrote:
> Just thought I’d share with you guys an article that among other things
> discusses how we at ArenaNet are using IronPython. We don’t go into many
> details about how important IronPython is to our editor, but we at least
> allude to it. Every time Python is mentioned it’s using IronPython J
>
>
>
> http://altdevblogaday.org/2011/03/13/before-you-wreck-yourself/
>
>
>
> Let me know if you have any questions about the boring details! We’re
> currently using 2.7A1, but that’s only because we haven’t taken the time to
> make sure that we’re immediately compatible with the later versions J
>
>
>
>
>
> Daniel Jennings
>
> ___
> 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

Re: [IronPython] numpy / IronClad?

[Jeff Hardy]

On Mon, Mar 14, 2011 at 11:30 AM, Chad Brockman  wrote:
> So I’m assuming no Silverlight then? For the same reasons?
>
>
>
> Thanks, Chad

I'm pretty sure Silverlight doesn't support native code, at least not
in the browser and phone.

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

Re: [IronPython] IronPython 2.7.1 & 3.x Development

[Jeff Hardy]

On Mon, Mar 14, 2011 at 7:50 AM, Vernon Cole  wrote:
> I was running a test of adodbapi -- IPy 2.7 RC2 ran it fine, but CPython 2.7
> had errors. I was starting to debug the CPython when I discovered that I was
> running the Python _3_ version of the test suite! The "error" was in the
> Unicode vs String logic. IronPython already does the right (P3k) thing.

Yep - the unicode support is the single biggest change in Py3k, and we
already support it. Pulling the new stdlib & tests in is easy as well.
There are some parser changes (function annotations) but even those
should be minor. I'm really optimistic.

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

[IronPython] IronPython 2.7.1 & 3.x Development

[Jeff Hardy]

With the 2.7 out the door, it's time to start thinking about 3.x. I've
created a ipy-2.7-maint branch for continued 2.7 work (and it needs
some), and any 3.x work will go on master. Any 2.7 fixes that also go
into 3.x (and really, most of them should) go into the 2.7 branch
*first*, and then be cherry-picked into master (yes, I'll write some
docs on that). This is to (hopefully) prevent any 3.x features from
being inadvertently backported to 2.7.

I'll pull in the 3.2 standard lib and tests very soon, and then work
on the parser/compiler changes and such can start. I'm not expecting
to have a reasonable 3.x release until fall at the earliest, although
I would like to get nightly builds set up so people can still try it
easily in the meantime.

For now, the 3.x series will have the 3.0 version number; whether it
becomes 3.2 or 3.3 remains to be seen.

There's still a lot of stuff that should go into 2.7.1 - bug fixes,
new modules, etc. Ideally I'd like to see that released in 6-8 weeks,
which puts it around the beginning of May, and then on basically the
same cycle as long as there's fixes to go in.

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

[IronPython] IronPython 2.7 Now Available

[Jeff Hardy]

On behalf of the IronPython team, I'm very pleased to announce the
release of IronPython 2.7. This release contains all of the language
features of Python 2.7, as well as several previously missing modules
and numerous bug fixes. IronPython 2.7 also includes built-in Visual
Studio support through IronPython Tools for Visual Studio. IronPython
2.7 requires .NET 4.0 or Silverlight 4.

To download IronPython 2.7, visit
http://ironpython.codeplex.com/releases/view/54498. Any bugs should be
reported at http://ironpython.codeplex.com/workitem/list/basic.

Python 2.7 includes a number of features backported from the Python
3.0 series. This release implements the new builtin _io module,
includes dictionary and set comprehensions, set literals, supports
multiple context managers in the with statement, and adds several new
functions to the itertools methods, and auto indexing for the new
string formatting. There are also numerous updates to the standard
library such as ordered dictionaries and the new argparse module.

This release also includes a “IronPython Tools for Visual Studio”
option within the IronPython installer. This enables one install to
get both IronPython and IronPython Visual Studio support assuming you
have an existing installation of Visual Studio 2010. This version of
IronPython Tools includes a number of bug fixes as improved WPF
designer support. The designer fully supports XAML and WPF including
data binding to Python classes dynamically.

To improve interop with modern .NET code such as LINQ, support for
extension methods has been added as the clr.ImportExtensions method.

We’ve also updated the IronPython installer to include documentation
based upon the CPython documentation. This new .chm file includes
documentation on the Python language and standard library. It’s been
extended from the normal Python documentation to include IronPython
specific topics such as the DLR hosting APIs and extending IronPython
from statically typed .NET languages.

We flushed out more support for missing built-in modules which CPython
includes. This release includes the mmap and signal modules bringing
better support for interoperating with unmanaged code, the zlib and
gzip modules for compression, and the subprocess and webbrowser
modules for interacting with other programs.

As usual there are a number of bug fixes and performance improvements.
This release includes major performance improvements in cPickle, the
sum built-in function, and includes support for fast exceptions which
do not use the .NET exception mechanism. There have also been
improvements to significantly reduce memory usage of the IronPython
ASTs. One of the end results of these numerous improvements is that
IronPython’s startup time has decreased by 10% when compared to
IronPython 2.6.1.

This is the first full community release of IronPython, and I want to
give a huge thank you to everyone who was involved in this release.

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

Re: [IronPython] IronPython @ PyCon 2011

[Jeff Hardy]

On Mon, Mar 7, 2011 at 11:24 AM, Michael Foord  wrote:
> Just don't clash with the testing BoF! (And sign up for it, last year it was
> epic.)

I'm specifically trying to avoid that one ... it better live up to the hype :).

> Maybe we can look at the Mac issue (sysconfig) during the sprints.

I won't be able to stay for the sprints, just Thu-Sun.

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

Re: [IronPython] IronPython @ PyCon 2011

[Jeff Hardy]

I'm going to try to organize an IronPython OpenSpace/BoF/sprint for
Fri/Sat. Page coming soon.

- Jeff

On Mon, Mar 7, 2011 at 9:42 AM, Jeff Hardy  wrote:
> I'll be there, and so will Dino (with something very cool to show
> off). Anybody else?
>
> - Jeff
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython @ PyCon 2011

[Jeff Hardy]

I'll be there, and so will Dino (with something very cool to show
off). Anybody else?

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

[IronPython] IronPython 2.7 RC 2 Available

[Jeff Hardy]

On behalf of the IronPython team, I am pleased to announce IronPython
2.7 Release Candidate 2. The releases contains a few minor bug fixes,
including a working webbrowser module.

http://ironpython.codeplex.com/releases/view/62114

This will be the last release before 2.7 Final. There are still a few
fixes that need to be done before I'm happy with the release,
including getting sysconfig to work reliably on Max/Linux. If you've
got one of those handy and want to a look at sysconfig.py (and
http://ironpython.codeplex.com/workitem/29841) it would be a huge
help.

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

Re: [IronPython] IronPython Hosting ?

[Jeff Hardy]

On Fri, Mar 4, 2011 at 9:42 AM, L. Lee Saunders  wrote:
> My biggest hurdle was running IronPython out of C++/cli.  I tried hand
> converting some working C# code but was failing.  I finally had to resort to
> RedGate's "Reflector" with the C++/cli plugin.  That did not produce working
> code either, but with its output and my attempts to hand convert, I was able
> to produce working code.

Can you share it? You're probably not the only person to try, and I'd
like to know what the differences from C# are.

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

Re: [IronPython] Ironpython and Berkeley License

[Jeff Hardy]

On Thu, Mar 3, 2011 at 8:23 AM, Markus Schaber
 wrote:
>  * 3. Redistributions in any form must be accompanied by information on
>  *    how to obtain complete source code for the DB software and any
>  *    accompanying software that uses the DB software.  The source code
>  *    must either be included in the distribution or be available for no
>  *    more than the cost of distribution plus a nominal fee, and must be
>  *    freely redistributable under reasonable conditions. [...]
> --- snap ---
>
> This seems to be a GPL-like viral license, which would be somewhat
> harassing for our current project.

IANAL, blah blah, but that doesn't read like the GPL, which requires
all *derivative works* to have the source available - that licence
just requires the source *to Berkeley DB* be made available.

In any case, Berkeley DB isn't even included, so it shouldn't be an issue.

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

Re: [IronPython] numpy / IronClad?

[Jeff Hardy]

Re: numpy - it sure looks like it:
https://github.com/numpy/numpy-refactor/tree/refactor/numpy/NumpyDotNet.
(last commit 2 days ago)

As for IronClad, I'm not sure - it doesn't look like it, and I'm not
sure Resolver is still using IronPython. I would love to see it rolled
into the main IronPython releases, though, if someone's up for a hell
of a challenge (and willing to commit to long term maintenance.

The CPython devs have talked about committing to a stable public ABI
for 3.3, which would help a lot. I'm not sure if that went any where
recently, though.

- Jeff

On Tue, Mar 1, 2011 at 3:32 PM, Chad Brockman  wrote:
> Anyone know if the effort to port numpy to IronPython is still alive?
> Enthought / MS announced it last year?
> http://www.enthought.com/media/SciPyNumPyDotNet.pdf
>
>
>
> Anyone know if IronClad is still being developed?
>
>
>
> Thanks, Chad
>
> ___
> 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

Re: [IronPython] IronPython Hosting ?

[Jeff Hardy]

On Mon, Feb 28, 2011 at 1:58 PM, Mark Senko  wrote:
> *Bill, what are your goals for asking how we use hosting?

While I can't speak for Bill, I can say hosting is something that
hasn't been given much thought in the last little while because I've
been focused on getting the engine and stdlib up to par, and because
the hosting APIs are, in general, very good. If there are specific
use-cases that aren't covered, it would be good to know.

> *I’m still discovering the features I have available, and lamenting those I
> don’t.

What don't you have available? What would you like to see added to the
hosting API? It's too late to get changes into 2.7, but 3.x is open
season as far as changes are concerned, no matter how crazy.

My use case: a WSGI implementation for serving web sites. It basically
just mooks for a callable in a .py file and calls it with particular
arguments. I have very few issues with the hosting API, although there
are a few missing helpers that would be nice to have.

What I think is missing the most is documentation - or if it exists,
I'm not sure where to find it. Especially for using other AppDomains,
as that comes up a lot.

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

[IronPython] Slight Delay in IronPython 2.7 Release

[Jeff Hardy]

Hi all,
The the RC2 and final IronPython 2.7 releases will be pushed back a
week, to March 6 and March 13.

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

Re: [IronPython] GSoC 2011: Interested Students

[Jeff Hardy]

Hi Afriza,
It appears that you are right - for some reason I thought mentoring
orgs had to show that there was student interest before applying, but
that doesn't seem to be the case.

I'm still going to send in the application and see what happens.

- Jeff

On Wed, Feb 23, 2011 at 4:59 PM, Afriza N. Arief  wrote:
> Hi,
>
> I think mentoring organizations don't need to "get students" before applying
> for GSoC.
>
> This will allow students who didn't know about the mentoring organization to
> join and start knowing and contributing.
>
> It will also be hard for students like me to contact potential organizations
> and check for potential projects before the organizations are accepted and
> listed in GSoC website.
>
> Once the organizations are accepted, students can browse, discover, and join
> the project that he never knew it exists.
>
> So I think you should just apply for it. What more Google wants to get more
> organizations and students this year.
>
> It will be a waste if you don't apply.
>
> Regards,
>
> Afriza N. Arief
>
> On Feb 23, 2011 6:24 AM, "Jeff Hardy"  wrote:
>
> ___
> 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

[IronPython] Authenticode Signing of Releases

[Jeff Hardy]

Older releases of IronPython were authenticode signed (by Microsoft),
but so far the community releases have not been. As best I can tell,
authenticode certificates are expensive (the cheapest are around
$100/year) - I've heard of deals for open source projects but can't
find anything by searching.

Is it even worth the hassle to get an authenticode cert for releases?
It adds a bit of extra polish to the installation, but I doubt many
people pay attention to that anyway.

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

Re: [IronPython] Road to IronPython 2.7 (update)

[Jeff Hardy]

Opened http://ironpython.codeplex.com/workitem/30240 as high priority. Thanks!

- Jeff

On Mon, Feb 21, 2011 at 5:01 PM, Steve Dower  wrote:
> The tools problem seems to be to do with the installer. IPyTools
> (PythonRuntimeHost.cs:89-100) tries to load the installed path from
> HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy
> 2.7 RC1 installed without IPyTools, which were built from source) this
> is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default)
> which contains "ipy64", which is then combined (PythonStarter.cs:69)
> with "ipy.exe" to make "ipy64\ipy.exe" as the interpreter path (which
> doesn't exist).
>
> If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my
> actual install path (where ipy.exe is) it works fine. I assume this
> should be done in the installer.
>
>
> Steve
>
> On Tue, Feb 22, 2011 at 10:12, Jeff Hardy  wrote:
>> Hi all,
>> The following issues are blockers for IronPython 2.7:
>>
>> * #29841 - sysconfig traceback when starting 2.7B1 -
>> http://ironpython.codeplex.com/workitem/29841
>> I don't know enough about Mono/MacOS/POSIX to fix this one properly. I
>> haven't yet chercked what the Mono guys did to get it working on
>> Linux.
>>
>> * (no issue) - Visual Studio tools
>> The Visual Studio tools are basically broken right now - I can't
>> launch or debug even the default console program. I think it's because
>> it can't find the interpreter, but I thought I fixed that already.
>>
>> * (no issue) - silverlight support
>> I have no idea what the status of the silverlight support is.
>>
>> Once these are resolved (one way of another) I think 2.7 will be ready to go.
>>
>> - Jeff
>>
>> P.S. In all honesty I would have preferred to call the latest release
>> Beta 3 instead of RC1, but I had already changed the version strings
>> and didn't want to change them back :|.
>> ___
>> 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

Re: [IronPython] Silent install of IronPython

[Jeff Hardy]

On Tue, Feb 22, 2011 at 6:50 PM, haniti grk  wrote:
> I am fine that some of the stuff goes to GAC but just wanted to install most
> of the stuff in c:\ipy. I checked IronPython.wxs and it seems like it should
> use INSTALLDIR option but it does not do it though.

This was reported against 2.7B1 in bug #29950 [1], but was also
reported as fixed in 2.7B2. If I set the install path to C:\ipy27\ in
the installer UI, it works fine. I tried using both INSTALLDIR and
TARGETDIR from the command line instead, but it just dumped it all in
the default directory.

- Jeff

[1] http://ironpython.codeplex.com/workitem/29950

>
> -Haniti
>
> ___
> 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

[IronPython] GSoC 2011: Interested Students

[Jeff Hardy]

Hi all,
Are there any students that are interested in doing some work on
IronPython/IronRuby/DLR for this year's Google Summer of Code? I'd
like to make sure there's enough interest before I commit to putting
together an application.

The current suggested projects list is at http://bit.ly/g7YhPT but
feel free to add more!

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

Re: [IronPython] Road to IronPython 2.7 (update)

[Jeff Hardy]

On Tue, Feb 22, 2011 at 11:55 AM, Tristan Zajonc  wrote:
> It appears to be because int is a very large long.  This is probably the
> core issue:
> In IronPython:
 a=143098242404177361603877621312831893704
> Traceback (most recent call last):
> OverflowError: Number overflow.
 a=143098242404177361603877621312831893704L
 a
> 143098242404177361603877621312831893704L

This works for me on .NET, so it's almost certainly a Mono bug. Can
you reproduce it in a C# program?

Doesn't mean we can't work around it, though, but I'd prefer not too.
I've bumped it to high priority; one way or another it'll get fixed
for 2.7.

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

Re: [IronPython] Road to IronPython 2.7 (update)

[Jeff Hardy]

On Tue, Feb 22, 2011 at 12:42 AM, Tristan Zajonc  wrote:
> IronPython 2.7 RC 1 (2.7.0.30) on .NET 4.0.30319.1
> Type "help", "copyright", "credits" or "license" for more information.
 import uuid
> Number overflow.
> at System.Numerics.BigInteger.op_Explicit (System.Numerics.BigInteger)
> <0x000aa>
> at Microsoft.Scripting.Utils.MathUtils.AsInt32
> (System.Numerics.BigInteger,int&) <0x00067>
> at IronPython.Runtime.Operations.BigIntegerOps.Compare
> (System.Numerics.BigInteger,int) <0x00028>
> at (wrapper dynamic-method) object.CallSite.Target
> (System.Runtime.CompilerServices.Closure,System.Runtime.CompilerServices.CallSite,object,object)
> <0x0011d>
> at System.Dynamic.UpdateDelegates.UpdateAndExecute2
> (System.Runtime.CompilerServices.CallSite,object,object) <0x00382>
> at Microsoft.Scripting.Interpreter.DynamicInstruction`3 object>.Run (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x000bc>
> at Microsoft.Scripting.Interpreter.Interpreter.Run
> (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x00077>
> OverflowError: Number overflow.

This *looks* like an issue in Mono, especially since it works on .NET.

Can you try computing '1<<128' on Mono? That seems to be the failing expression.

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

[IronPython] Road to IronPython 2.7 (update)

[Jeff Hardy]

Hi all,
The following issues are blockers for IronPython 2.7:

* #29841 - sysconfig traceback when starting 2.7B1 -
http://ironpython.codeplex.com/workitem/29841
I don't know enough about Mono/MacOS/POSIX to fix this one properly. I
haven't yet chercked what the Mono guys did to get it working on
Linux.

* (no issue) - Visual Studio tools
The Visual Studio tools are basically broken right now - I can't
launch or debug even the default console program. I think it's because
it can't find the interpreter, but I thought I fixed that already.

* (no issue) - silverlight support
I have no idea what the status of the silverlight support is.

Once these are resolved (one way of another) I think 2.7 will be ready to go.

- Jeff

P.S. In all honesty I would have preferred to call the latest release
Beta 3 instead of RC1, but I had already changed the version strings
and didn't want to change them back :|.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython 2.7 Release Candidate 1 is now available

[Jeff Hardy]

On behalf of the entire IronPython team:

We are pleased to announce the first Release Candidate for IronPython
2.7[1]. This release contains over two dozen bugs fixed in preparation
for 2.7 Final.

See the release notes for 2.7 Beta 2[2] for details and what has
already been fixed in the earlier 2.7 prereleases.

- IronPython Team

[1] http://ironpython.codeplex.com/releases/view/61395
[2] http://ironpython.codeplex.com/releases/view/60193
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?

[Jeff Hardy]

On Mon, Feb 21, 2011 at 11:58 AM, Brian Curtin  wrote:
> I think this would be better suited in the standard library at
> svn.python.org, rather than just within IronPython. Thoughts on that? I
> haven't followed long enough to know how standard library changes are
> usually handled around here, but you'd have to re-apply this change whenever
> re-syncing.

Generally we prefer to remain as close as possible to the CPython
stdlib, but I think the 2.7 stdlib is pretty much frozen at this
point. When switching to the 3.x stdlib, we'll figure out what can be
pushed upstream and what should maybe be IronPython-specific.

I'm hoping that, with 3.2 now out, the process of splitting off the
stdlib can proceed, but I think it's held up by the hg transition as
well. That would be ideal.

> As for the change, wouldn't it be cleaner to make a shortcut like """windows
> = sys.platform in ["win32", "cli"]""" and then test """if windows:"""?

The problem is that just 'cli' != 'windows' - it could be running on
Linux or MacOS via Mono. The best I've found for identifying Windows
is:

sys.platform == 'win32' or (sys.platform == 'cli' and os.name == 'nt')

or, just:

os.name == 'nt'

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

Re: [IronPython] How do you detect operating systems from within IronPython?

[Jeff Hardy]

On Mon, Feb 21, 2011 at 11:05 AM, Vernon Cole  wrote:
> How should I really be doing it?

os.name usually has the actual underlying OS, but depending on what
you need to do it may be better to have a block that is just for 'cli'
that calls into a .NET API, and let .NET/Mono smooth over the platform
differences.

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

[IronPython] 2.7 RC1 postponed

[Jeff Hardy]

Hi all,
The first 2.7 RC was scheduled for today, but due to other commitments
I probably won't get it packaged until tomorrow.

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

Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?

[Jeff Hardy]

Github is the master source. And yes, the various websites need
straightening out.

- Jeff

On Sun, Feb 20, 2011 at 9:42 AM, Vernon Cole  wrote:
> I've lost my link, and cannot muddle my way to meaningful results on either
> Codeplex, Wikepedia or Github. Github actually refers me back to Codeplex,
> where the most recent release is October of last year.
> What is the URL to the real, true, current official source for IronPython?
> --
> Vernon Cole
>
>
> ___
> 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

Re: [IronPython] Fwd: Status updated to Closed for Issue: distutils "install" command will not install a simple module. [IronPython: 28530]

[Jeff Hardy]

Hi Vernon,
A little of both, actually - we have a copy of the Python stdlib, and
there are some modifications to it, but the goal is to stay as close
as possible to the CPython stdlib.

If you supply a patch upstream, I'll apply it to our copy because it
affects us more than CPython, and it likely won't make production
until 3.3.

I wouldn't worry about trying to determine if elevation is required -
just 'write access denied' should be enough.

- Jeff

On Sat, Feb 19, 2011 at 11:06 PM, Vernon Cole  wrote:
> Jeff:
>   You are right to close this bug -- I made a bad report based on an
> incorrect assumption. But I would not have been led astray if the error
> message had not been so obscure.  It should SAY just exactly what you said:
> "elevation is required."  IMHO the distutils error reporting should be
> improved.
>  My question for you: Is IronPython distutils a special version (and we can
> fix it here) or straight from the Python Standard Library (and it must be
> fixed there)?
>   Perhaps I can supply a patch, but I need to know where to send it.
> --
> Vernon
>
> -- Forwarded message --
> From: 
> Date: Sat, Feb 19, 2011 at 3:53 AM
> Subject: Status updated to Closed for Issue: distutils "install" command
> will not install a simple module. [IronPython: 28530]
> To: vernondc...@gmail.com
>
>
> User jdhardy has updated Issue: distutils "install" command will not install
> a simple module..
>
> Status has changed from Proposed to Closed with the following comment,
>
> "This is 'By Design'. Elevation is required to write to C:\Program Files."
>
>
> View the full issue online.
>
> You are receiving this email because you are tracking this work item on
> IronPython. You can unsubscribe at CodePlex.com. This is an unmonitored
> account.
>
> ___
> 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

Re: [IronPython] Bugfix for 2.7B2 allows pdb to run.

[Jeff Hardy]

Patch applied. Thanks!

- Jeff

On Wed, Feb 16, 2011 at 8:12 AM, Andrés Martinelli  wrote:
> Hi,
>
>  I have fixed a bug in 2.7B2 which prevented pdb from running.
>
>  The problem is due to an exception thrown when accessing the
> f_globals property of a frame.
>
>  I've reported the bug details (
> http://ironpython.codeplex.com/workitem/30177 ) and attached a patch
> with a one line fix.
>
>  Please review and let me know if I can provide any further assistance.
>
> cheers,
> Andrés
> ___
> 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

Re: [IronPython] Additional modules to ship with IronPython 2.7.1?

[Jeff Hardy]

On Wed, Feb 16, 2011 at 8:18 AM, Brian Curtin  wrote:
> On Wed, Feb 16, 2011 at 08:30, Jeff Hardy  wrote:
>>
>> On Wed, Feb 9, 2011 at 12:47 PM, Vernon Cole 
>> wrote:
>> > Dear Group:
>> >    I would like to start a discussion about adding modules to the
>> > IronPython
>> > distribution which are not in the C-Python standard library. The idea
>> > would
>> > be to include more batteries.  (FePy started out to do that, but has not
>> > been seriously updated since IronPython 2.0 came out with a real,
>> > genuine
>> > Windows installer.)  Good idea, or Bad?
>>
>> We certainly don't have to restrict ourselves to the same set of
>> batteries as CPython. However, I'd be cautious about adding in too
>> much simply because we don't have a huge pool of committers at the
>> moment.
>
> Something to be careful of is inclusion of external code that still evolves
> outside of the stdlib. When I install 2.7.1 complete with xyz library, a
> week later when the author comes out with a great new feature, my install is
> already out of date.

That's my biggest concern. As someone said, the stdlib is where code
goes to die :).

Another consideration is that the Python stdlib may one day become its
own project, and we may not want to diverge from it.

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

Re: [IronPython] Additional modules to ship with IronPython 2.7.1?

[Jeff Hardy]

On Wed, Feb 9, 2011 at 12:47 PM, Vernon Cole  wrote:
> Dear Group:
>    I would like to start a discussion about adding modules to the IronPython
> distribution which are not in the C-Python standard library. The idea would
> be to include more batteries.  (FePy started out to do that, but has not
> been seriously updated since IronPython 2.0 came out with a real, genuine
> Windows installer.)  Good idea, or Bad?

We certainly don't have to restrict ourselves to the same set of
batteries as CPython. However, I'd be cautious about adding in too
much simply because we don't have a huge pool of committers at the
moment.

>
>   I see that adodbapi is still getting about 300 downloads a month, and I
> presume that most of them are for IronPython, since it's already included in
> pywin32 for CPython users. FePy is getting around 50 downloads a month,
> which I guess is mostly  to get the dbapi modules. The FePy modules are
> lighter in weight than adodbapi, and use genuine .NET system calls, but are
> not completely PEP 249 compliant.  Adodbapi is compliant, but uses COM to
> read the database, so will not run on linux/mono. Should db api and/or other
> modules be considered for inclusion?

In the case of adodbapi, the lack of Mono support is slightly
troubling. It's really too bad that dbapi cannot be mapped onto
ADO.NET, but them's the breaks.

Another thing to consider is that a working distutils (and something
like pip) eliminates a lot of the need to have the batteries included.
There's still a bit of work needed to get pip working, but I hope to
have that into 2.7 or 2.7.1.

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

Re: [IronPython] sqlite3 + IP 2.7

[Jeff Hardy]

Hi Guillermo,
I haven't tried that module against 2.7 in a while, but it should
mostly work. You'll have to build from source and adjust the
references to point to 2.7B2 - the downloadable packages are 2.6 only.

I'll update the downloads to 2.7 shortly after it's released.

- Jeff

On Mon, Feb 14, 2011 at 3:46 PM, Guillermo López
 wrote:
> Hello all,
> I've managed to get the sqlite3 module
> (https://bitbucket.org/jdhardy/ironpython.sqlite/src) working under
> IronPython 2.6, but it doesn't seem to work with 2.7. I couldn't find any
> info about compatibility with 2.7, so I'd like to know whether this is a
> known issue or maybe the installation instructions for 2.7 are different?
> The specific error I'm getting is that IronPython can't import the _sqlite3
> module.
> Regards,
> Guillermo
> ___
> 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

Re: [IronPython] Non-English Version of Win XP needed

[Jeff Hardy]

Thanks, guys! I'll close it off now.

- Jeff

On Mon, Feb 14, 2011 at 7:03 AM, Slide  wrote:
> On Sun, Feb 13, 2011 at 10:15 PM, Simon Dahlbacka
>  wrote:
>> Works for me also.  Swedish xp(sv-FI)
>>
>> On Feb 14, 2011 7:11 AM, "Jeff Hardy"  wrote:
>>> I'd like one other person to confirm this is fixed before I close -
>>> Spanish or German preferably, since they are mentioned in the bug.
>>>
>>> - Jeff
>>>
>>> On Sun, Feb 13, 2011 at 12:20 AM, Jörgen Stenarson
>>>  wrote:
>>>> Jeff Hardy skrev 2011-02-13 06:25:
>>>>>
>>>>> It looks like http://ironpython.codeplex.com/workitem/14022 will only
>>>>> repro on non-english versions of XP that use , as the decimal
>>>>> separator instead of .
>>>>>
>>>>> If you have one of those, can you see if the issue is still present in
>>>>> 2.7B2. From the notes, it looks like just changing the locale is not
>>>>> enough - it has to be a non-english version.
>>>>>
>>>>> - Jeff
>>>>> ___
>>>>> Users mailing list
>>>>> Users@lists.ironpython.com
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>> Hi,
>>>>
>>>> I could not reproduce the problem on my machine (swedish windows xp)
>>>>
>>>> IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>>> 3.14
>>>> 3.14
>>>>>>> 3,14
>>>> (3, 14)
>>>>>>> import math
>>>>>>> 3.14159265359
>>>> 3.14159265359
>>>>>>> float(repr(float(repr(math.pi
>>>> 3.141592653589793
>>>>>>>
>>>>
>>>> /Jörgen
>>>> ___
>>>> 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
>>
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
> I installed a German version of Windows in a VM and it behaves the
> same as CPython 2.7
>
> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] 
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 3.14
> 3.14
>>>> 3,14
> (3, 14)
>>>> import math
>>>> math.pi
> 3.141592653589793
>>>> float(repr(float(repr(math.pi
> 3.141592653589793
>>>> ^Z
>
>
> IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 3.14
> 3.14
>>>> 3,14
> (3, 14)
>>>> import math
>>>> math.pi
> 3.141592653589793
>>>> float(repr(float(repr(math.pi
> 3.141592653589793
>>>> ^Z
>
>
>
>
> --
> 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

Re: [IronPython] Non-English Version of Win XP needed

[Jeff Hardy]

I'd like one other person to confirm this is fixed before I close -
Spanish or German preferably, since they are mentioned in the bug.

- Jeff

On Sun, Feb 13, 2011 at 12:20 AM, Jörgen Stenarson
 wrote:
> Jeff Hardy skrev 2011-02-13 06:25:
>>
>> It looks like http://ironpython.codeplex.com/workitem/14022 will only
>> repro on non-english versions of XP that use , as the decimal
>> separator instead of .
>>
>> If you have one of those, can you see if the issue is still present in
>> 2.7B2. From the notes, it looks like just changing the locale is not
>> enough - it has to be a non-english version.
>>
>> - Jeff
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> Hi,
>
> I could not reproduce the problem on my machine (swedish windows xp)
>
> IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 3.14
> 3.14
>>>> 3,14
> (3, 14)
>>>> import math
>>>> 3.14159265359
> 3.14159265359
>>>> float(repr(float(repr(math.pi
> 3.141592653589793
>>>>
>
> /Jörgen
> ___
> 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

Re: [IronPython] Issue triage

[Jeff Hardy]

I've closed the closeable issues. Thanks for looking at these!

- Jeff

On Sun, Feb 13, 2011 at 11:08 AM, Andrés Martinelli
 wrote:
> Hi,
>
> I have checked out a few work items:
>
>  Not reproducible in 2.7B2:
>
>    - #26940/Medium/2.7:
>      Wrong line numbers in traceback when ecoding is specified
>      ( http://ironpython.codeplex.com/workitem/26940 )
>      could be closed.
>
>    - #23650/Medium/2.6.2:
>      Pdb set_trace and post_mortem
>      ( http://ironpython.codeplex.com/workitem/23650 )
>      Could be closed.
>
>    - #12876/Medium/No release:
>      Support getting stack trace of script code (sys._getframe)
>      ( http://ironpython.codeplex.com/workitem/12876 )
>      Could be closed.
>
>  Reproducible in 2.7B2:
>
>    - #25543/Medium/2.6.2:
>      Traceback Stack Functions Don't Work
>      ( http://ironpython.codeplex.com/workitem/25543 )
>
>    - #25218/Low/No release:
>      Modules can get executed several times when an ImportError
> exception is raised
>      ( http://ironpython.codeplex.com/workitem/25218 )
>
> I have added the details in comments to each of them.
>
> I hope it helps,
> /Andrés
> ___
> 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

[IronPython] Must-fix bugs for 2.7

[Jeff Hardy]

Here is the current list of must-fix bugs for 2.7: http://bit.ly/gQRTSn

Basically, anything with a Release of 2.7 and a Priority of High. If
you have a bug you think should be on that list, just let me know, or
set those fields.

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

[IronPython] Non-English Version of Win XP needed

[Jeff Hardy]

It looks like http://ironpython.codeplex.com/workitem/14022 will only
repro on non-english versions of XP that use , as the decimal
separator instead of .

If you have one of those, can you see if the issue is still present in
2.7B2. From the notes, it looks like just changing the locale is not
enough - it has to be a non-english version.

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

Re: [IronPython] Reminder: First IronPython Bug Weekend is this this weekend

[Jeff Hardy]

I've set up a spreadsheet for keeping track of who's working on what
bugs; it's at 
https://spreadsheets.google.com/ccc?key=0AlhyN5J6eVpldEFlcEhETjlRRnB0TnZ2RDNBLTMzdlE&hl=en.
If you're working on a bug, *please* record it there so people don't
duplicate effort.

If you want to write a patch and want something easy to start with,
here are a couple of really easy ones:

* http://ironpython.codeplex.com/workitem/27656
* http://ironpython.codeplex.com/workitem/29914
* http://ironpython.codeplex.com/workitem/29928

If you find another easy bug, add 'easy' to the Custom field.

Figuring out which bugs are still valid and which aren't is a big part
of this weekend, so bugs that are missing reproduction steps or test
cases should have them added.

If a bug has a patch or test case, add 'hastest' or 'haspatch' to the
Custom field.

- Jeff

On Fri, Feb 11, 2011 at 12:53 AM, Jeff Hardy  wrote:
> This is just a firendly reminder that the first IronPython Bug Weekend
> is this weekend, February 12-13. You can find more information at
> http://ironpython.codeplex.com/wikipage?title=first%20IronPython%20Bug%20Weekend.
>
> Remember, you don't have to dedicate the whole weekend - even finding
> a couple of hours to write a patch will help out a lot!
>
> - Jeff
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Reminder: First IronPython Bug Weekend is this this weekend

[Jeff Hardy]

This is just a firendly reminder that the first IronPython Bug Weekend
is this weekend, February 12-13. You can find more information at
http://ironpython.codeplex.com/wikipage?title=first%20IronPython%20Bug%20Weekend.

Remember, you don't have to dedicate the whole weekend - even finding
a couple of hours to write a patch will help out a lot!

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

Re: [IronPython] Red Flag(?) change in "import"

[Jeff Hardy]

On Thu, Feb 10, 2011 at 6:11 PM, Dino Viehland  wrote:
> If no one else steps up to look at it I can take a look this weekend.  But
> let me tell everyone fixing import bugs is awesome fun!

That sounds like sarcasm to me...

> I thought adodbapi was still part of the test suite but I don’t know how it
> transitioned when MS gave the project to the community.  It may have not
> been pushed out and may need to be re-added.

I'm pretty sure it wasn't removed, so it might just have never been there.

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

Re: [IronPython] Google Summer of Code 2011

[Jeff Hardy]

On Wed, Feb 9, 2011 at 12:09 PM, Daniel D.  wrote:
> I know what I want for Christmas:
>
> PEP  compliant, WSGI Server for IIS 6.x and 7.x.

Well, that gives me quite a bit of time then :). NWSGI 3 will have to
wait until after 2.7 final, but hopefully not too long after.

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

Re: [IronPython] Google Summer of Code 2011

[Jeff Hardy]

On Wed, Feb 9, 2011 at 7:35 AM, Slide  wrote:
> Fyi, I am almost done with an implementation of _csv

Excellent!

The next release (Feb.20)  will be the last one to get it into before
2.7 final. If it's not going to be ready by then, don't worry; I'm
thinking I might target 2.7.1 for early April just to toss in extra
modules. I've got a unicodedata implementation that won't be ready,
but just needs a bit of work, and possibly sqlite3 as well.

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

[IronPython] Google Summer of Code 2011

[Jeff Hardy]

Google is running their "Summer of Code" program [1] again this year.
For those who aren't familiar, Google basically pays post-secondary
students to work on open source projects for the summer.

Now that IronPython and IronRuby are community projects, I think it
would be worthwhile to for us to participate. In a chat with Miguel,
he suggested that we apply as a group ("IronLanguages") representing
both languages and the DLR.

If there are no serious objections, I'm willing to submit the
application and handle the organization administrative tasks.

One of the things that is needed on the application is ideas for
projects. These don't have to be fully fleshed out ideas; just
something to give Google an idea of what we would be working on.

You can view and edit the list (anyone can edit ... don't abuse it!)
at http://bit.ly/g7YhPT. I've added a few examples for IronPython to
get started. Ideas can also be sent to this mailing list and I'll add
them to the list.

Prospective students, in particular, are encouraged to submit their
ideas ahead of time.

- Jeff

[1] http://www.google-melange.com/gsoc/program/home/google/gsoc2011
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Merges

[Jeff Hardy]

Hi Daniel,
When working, I do all of my work in a branch, and then merge that
branch into master. On that branch I usually rebase changes from
upstream/master. However, I don't like rebasing onto master because it
just looks weird. I want to see the merge commit to master so that I
know it happened, and github can generate pretty graphs [1] :).

In summary:
- rebase feature/working branches
- merge master (or long-lived maintenance branches, etc.)

Of course, once in a while I forget to add --rebase :). Didn't know
you could default it on, which would be nice for working branches.

- Jeff

[1] https://github.com/IronLanguages/main/network

On Tue, Feb 8, 2011 at 1:37 PM, Daniel D.  wrote:
> Hi. Seeing J.Hardy do a merge of TMat's published changes into his
> local (very likely result of "git pull origin") and pushing that up,
> could not stop but wonder why on minor (no-feature) commits "rebase"
> is not not used to make the commit tree a bit more sane-looking. (My
> insignificant beef here is that TMat's commits were published first,
> and then, suddenly appeared as part of some branch JHardy pushed. Not
> a biggie, just slightly harder to keep track of changes.)
>
> Today stumbled upon a great explanation of what to do for minor
> (non-feature) commits to avoid constant remerging resulting from "git
> pull":
>
> ( from here http://mislav.uniqpath.com/2010/07/git-tips/ )
>
> Pull with rebase instead of merge
> $ git pull --rebase
> # e.g. if on branch "master": performs a `git fetch origin`,
> # then `git rebase origin/master`
> Because branch merges in git are recorded with a merge commit, they
> are supposed to be meaningful—for example, to indicate when a feature
> has been merged to a release branch. However, during a regular daily
> workflow where several team members sync a single branch often, the
> timeline gets polluted with unnecessary micro-merges on regular git
> pull. Rebasing ensures that the commits are always re-applied so that
> the history stays linear.
>
> You can configure certain branches to always do this without the --rebase 
> flag:
> # make `git pull` on master always use rebase
> $ git config branch.master.rebase true
> You can also set up a global option to set the last property for every
> new tracked branch:
> # setup rebase for every tracking branch
> $ git config --global branch.autosetuprebase always
>
> Daniel.
> ___
> 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