Re: [Ironpython-users] IronPython 2.7.1 Beta 1 now available

[Steve Dower]

Seems the link is actually http://ironpython.codeplex.com/releases/view/68588

And a quick note that this doesn't install side-by-side with 2.7 - the
earlier version is uninstalled. (I don't see this as an issue, but it
was a surprise.)

On Sat, Jun 18, 2011 at 22:05, Jeff Hardy  wrote:
> This is the first beta release of IronPython 2.7. Like IronPython 2.7,
> this release requires .NET 4 or Silverlight 4.
>
> The highlights of this release are:
>
> * Updated the standard library to match CPython 2.7.2.
> * Add the ast, csv, and unicodedata modules.
> * Fixed several bugs.
> * IronPython Tools for Visual Studio are disabled by default. See
> http://pytools.codeplex.com for the next generation of Python Visual
> Studio support.
>
> In particular, the updated standard library may have introduced some
> undetected bugs. Please report any issues at
> http://ironpython.codeplex.com/workitem/list/basic.
>
> You can download IronPython 2.7.1 Beta 1 at
> http://ironpython.codeplex.com/releases/view/62475.
>
> - Jeff
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Automating Visual Studio with IronPython

[Steve Dower]

The MSDN docs show the difference between the two:

http://msdn.microsoft.com/en-us/library/envdte.events.solutionevents.aspx
http://msdn.microsoft.com/en-us/library/envdte.events.outputwindowevents.aspx

In short, OutputWindowEvents takes an (optional) parameter. You don't
see this in C# because it doesn't support parameterised properties,
but neither does Python (though you can fake it with __getitem__). If
you 'call' the property (or is that call the 'property'?) it will get
the value:

EnvDTE._dispOutputWindowEvents_Event.add_PaneUpdated(dte.Events.OutputWindowEvents(),
onupdated)

The other thing to keen in mind with EnvDTE events is that you have to
keep the event objects alive or you will stop receiving notifications,
so you will at least need to do:

Events_OutputWindowEvents = dte.Events.OutputWindowEvents()
EnvDTE._dispOutputWindowEvents_Event.add_PaneUpdated(Events_OutputWindowEvents,
onupdated)

and make sure that Events_OutputWindowEvents doesn't get collected.

On Sun, Jun 26, 2011 at 04:23, Denis  wrote:
> Hi
> I am trying to automating some boring task by writing macros for
> Visual Studio 2010.
> I am not a .NET nor C# expert, I work with C++ and have some Python 
> background.
> So Python seemed more comfortable for me to do the task.
>
> What I got stuck on is receiving Visual Studio events.
> Some of them can be handled well but other are not.
> By irony, the latters events are the ones that needed to be handled.
>
> Ok, let us start from IronPython console in Visual Studio 2010.
>
>
>>> import clr
>>> clr.AddReference("EnvDTE")
>>> import EnvDTE, System.Runtime.InteropServices.Marshal
>>> dte = 
>>> System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE")
>
>>> def onopen(): print 'solution opened!'
>>> EnvDTE._dispSolutionEvents_Event.add_Opened(dte.Events.SolutionEvents, 
>>> onopen)
>
>
> Ok, the event installed and even works fine.
> Lets go on.
>
>
>>> def onupdated(): print 'pane updated!'
>>> EnvDTE._dispOutputWindowEvents_Event.add_PaneUpdated(dte.Events.OutputWindowEvents,
>>>  onupdated)
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: expected _dispOutputWindowEvents_Event, got DispCallable
>
>>» print type(dte.Events.OutputWindowEvents)
> 
>
>>» print type(dte.Events.SolutionEvents)
> 
>
>
> Oops.
> Seems like dte.Events.SolutionEvents and dte.Events.OutputWindowEvents
> are not similar at all.
> Why do they have so different type?
> Both events works similar way with VisualBasic.
>
> Thinking that DispCallable may have something todo with IDispatch,
> lets try another way:
>
>
>> dte.Events.OutputWindowEvents("add_PaneUpdated", onupdated)
> Traceback (most recent call last):
>  File "", line 1, in 
> StandardError: Error while invoking OutputWindowEvents.
>
>
> Oops again :(
> So how to deal with DispCallable?
> How to query interface _dispOutputWindowEvents_Event on it?
>
> Thanks in advance.
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Options for debugger for DLR languages on Mono

[Steve Dower]

Dino will know better than I do, but most if not all the C++ code in
PTVS is for debugging, but only for attaching to running CPython
processes. Otherwise, the debugger is largely based around a
'settrace' script and a C# debug engine communicating through sockets
- nothing to do with the DLR.

The DLR debugger is still in there though, but I have no idea how easy
it is to separate the two. You may want to look at the old IronPython
Tools (https://github.com/IronLanguages/main/tree/master/Tools/IronStudio),
since they won't have any of the CPython support, though there are
bugs that were fixed in PTVS since IPyTools were last updated.

On Wed, Sep 21, 2011 at 13:30, Dave Wald  wrote:
> Doug,
> First off, congrats on the Calico project. Seriously cool. I wish I was one
> of your students just starting out.
> These kids today... jeez.
> Anyway, if I was gonna tackle that project, first thing I would do is
> download the source code for PyTools for Visual Studio (it does CLR/DLR and
> CPython)
> http://pytools.codeplex.com/SourceControl/list/changesets
> and study it til I puked.
> Secondly, I would do the same with MonoDevelop, and do the old
> compare-and-contrast drill.
> Write myself a white-paper, as it were. Profusely annotated and
> Visio-diagrammed unto death.
> And then outline what I could re-use as is and where I needed to do major
> surgery.
> (Or get the students to do it... ;-)   )
> PyTools is written in C# mostly, looks like, with a sprinkling of C++/unsafe
> native code, but not in the debuggers. They look like straight cs.
> I have no idea what MonoDevelop looks like under the hood.
> But between the two, I would expect to be able to get a pretty good idea
> what could  be done without re-inventing the world.
>
> That's my two cents...
>
> Best,
> Dave
>
> On 9/19/2011 8:09 AM, Doug Blank wrote:
>>
>> IronPython users,
>>
>> We have a fairly robust editor/shell written in IronPython, using
>> Gtk#, running under cross-platform Mono with abilities to switch
>> between many languages (including Python, Ruby, Scheme, Lua, FSharp,
>> CSharp, Boo, and a new visual Scratch-based language called Jigsaw.
>> Although not all are DLR-based.) [1].
>>
>> What would be the best option for creating an interactive debugger for
>> the DLR languages on Mono? We would want to be able to set
>> break-points, single step, and inspect local variables. Ideally, this
>> would be a generic, language-neutral API, but if we have to do one for
>> each language, that might work too. Things we've looked at:
>>
>> a) Seo's FePy Mono Profiler, but that seems too low-level, and
>> requires C code for each platform.
>>
>> b) Microsoft.Scripting.Debugging [3], but will that work under Mono?
>>
>> c) sys.settrace(), but that would be Python-specific, and can't
>> single-step (?)
>>
>> Are there other issues/options to consider? Please feel free to point
>> me towards useful resources.
>>
>> Thanks!
>>
>> -Doug
>>
>> [1] - http://calicoproject.org/
>> [2] - http://fepy.blogspot.com/2007/06/pyprof-progresses.html
>> [3] - http://devhawk.net/2009/07/08/microsoft-scripting-debugging/
>> ___
>> Ironpython-users mailing list
>> Ironpython-users@python.org
>> http://mail.python.org/mailman/listinfo/ironpython-users
>>
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Metro Profile support

[Steve Dower]

It should 'just work' for desktop apps, maybe some changes to get
access to some of WinRT through the .NET projection, though there
isn't much worth having unless you're a Metro app.

Given IronPython runs on Mono/*nix as-is (ie. lack of PInvokes), there
shouldn't be too much preventing it from being hosted in a managed
Metro app, depending on exactly which .NET APIs have been removed --
there will be WinRT substitutes for these. The entry point is
important to get the proper message loops running, otherwise the async
APIs won't work properly.

I'm not sure exactly how Metro apps deal with the GAC (I suspect
they'll ignore it) but it should be possible to package IronPython
releases up separately and apps can take a dependency on it (the VC
runtime works like this). This still requires an executable stub in
the main app, but won't need winmd files for IronPy. Building/signing
a package manually is a pain, but if
http://pytools.codeplex.com/workitem/531 gets enough votes we may get
PTVS support (to match C#/C++/JS).

On Tue, Nov 22, 2011 at 06:46, Tomas Matousek
 wrote:
> I'm also going to look at porting DLR and Iron* languages to Win8 in next 
> couple of months -- to see what's blocking it if anything.
> Not promising anything though :)
>
> Tomas
>
> -Original Message-
> From: ironpython-users-bounces+tomas.matousek=microsoft@python.org 
> [mailto:ironpython-users-bounces+tomas.matousek=microsoft@python.org] On 
> Behalf Of Jeff Hardy
> Sent: Monday, November 21, 2011 11:38 AM
> To: Keith Rome
> Cc: ironpython-users@python.org
> Subject: Re: [Ironpython-users] Metro Profile support
>
> On Mon, Nov 21, 2011 at 11:33 AM, Keith Rome  wrote:
>> I specifically asked during the Q&A after that session about DLR support. 
>> With the changes to the type system, they seem to really want to push away 
>> from IDMOP. I also got the impression that "dynamic" in C# 4.5 will not be 
>> quite the same (perhaps Call Sites aren't going to work?). It seems to me 
>> that if either of those changed a lot it might break quite a bit of the DLR 
>> pieces.
>>
>> Getting a straight answer on the topic was pretty difficult though; nobody 
>> with a blue badge wanted to discuss it. It was either still up in the air, 
>> or they wanted to pretend it didn't exist. The official response seemed to 
>> always fall back to "you can still do it in 'classic' non-metro desktop apps 
>> in win8 if you need to".
>
> Hooray for non-answers! Not being able to use IronPython for Metro apps is 
> going to hurt in the future, methinks. I'll see what I can dig up.
>
> - Jeff
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
>
>
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Scripting Ansys with IronPython - Unable to callvalues from dictionary

[Steve Dower]

Probably the keys aren't actually strings but repr() has been
overridden. You could copy the dict with
  dict((repr(key), verifiedValues[key]) for key in verifiedValues)
to get one like you expect (though it may add quotes around the key).

Or you can
  print type(verifiedValues.keys()[0])
and see what you're actually dealing with.

On Fri, Nov 25, 2011 at 21:13, Markus Schaber  wrote:
> Hi,
>
> Von: Ossi Heinonen
>> That gives me
>>
>>    print verifiedValues[dict.keys(verifiedValues)[0]]
>>    5.5 [mm]
>>
>>Which is pretty damn exactly what I need! Thank you very much! The only 
>>problem now is that the order of the keys seems a bit random but maybe I can 
>>find some pattern for that.
>
> My guess is that the String for the Key is not exactly what you expect.
>
> Can you give us the output of the following command:
>
> for c in dict.keys(verifiedValues)[0]:
>    print "%s: '%s'"%(ord(c), c)
>
> Maybe some strange characters (like zero-width space or so) will show up.
>
> And if not, you can still use the ord values to create a matching key string 
> using chr().
>
> Markus
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
> Best regards
>
> Markus Schaber
> --
> ___
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
> +49-831-54031-50
>
> Email: m.scha...@3s-software.com | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects: 
> http://www.3s-software.com/index.shtml?sample_projects
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
> register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] IronPython 2.7.3 Alpha 1 Available

[Steve Dower]

Use http://ironpython.codeplex.com/releases/view/86886

Just a copy-paste issue in the original email (had "edit" instead of "view").

Steve

On Mon, Apr 30, 2012 at 03:04, Vernon Cole  wrote:
> Jeff, we have a problem!
>
> When I try the download link, I get:
> "
>
> Project Access Violation
>
> I'm sorry, but you tried to access a page or operation that is not permitted
> with your current credentials. For example, you need to be a member of a
> project to edit its work items.
>
> "
> I am only an editor, not a developer.
> --
> Vernon
>
>
> On Sun, Apr 29, 2012 at 2:28 AM, Jeff Hardy  wrote:
>>
>> On behalf of the IronPython team, I'm happy to announce the first
>> preview release of IronPython 2.7.3, which can be downloaded from
>> http://ironpython.codeplex.com/releases/edit/86886. This release
>> includes everything from IronPython 2.7, 2.7.1, and 2.7.2.1 as well.
>> Like all IronPython 2.7-series releases, .NET 4 is required to install
>> it. Installing this release will replace any existing IronPython
>> 2.7-series installation.
>>
>> IMPORTANT: There is a known issue if IronRuby 1.1.3 is installed
>> (2.7.2.1 "load language" problem). You must uninstall IronRuby before
>> installing IronPython 2.7.3. This will be resolved before the final
>> 2.7.3 release.
>>
>> The biggest improvements in IronPython 2.7.3 are:
>> * the winsound and _bisect modules,
>> * support for response files in pyc.py,
>> * support for loading zip packages from resources,
>> * the "SuperConsole" is now the default, which adds line history and
>> tab-completion on all platforms,
>> * improvements to Android support,
>> * and miscellaneous other bug fixes.
>>
>> IronPython 2.7.3 is also available for embedding via NuGet. The main
>> package is IronPython, and the standard library is in
>> IronPython.StdLib. Because this is a prerelease package, you must use
>> -IncludePrerelease on the command line or select "Include Prerelease"
>> from the package drop-down menu (NuGet 1.7 only).
>>
>> A huge thanks to everyone who helped make this release possible; this
>> wouldn't have been nearly as big a release without your help!
>> ___
>> Ironpython-users mailing list
>> Ironpython-users@python.org
>> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Poor performance of a c# - Ironpython application

[Steve Dower]

I'll throw in that exceptions are much faster in CPython than
IronPython (.NET generally), so if you have any exceptions being
thrown you'll want to find ways to avoid (not just handle) them.

On Thu, May 24, 2012 at 4:46 AM, Dino Viehland  wrote:
> This will help with startup, but not necessarily with throughput (it might 
> actually
> hurt it!).  But it can also help w/ profiling because if you're pre-compiled 
> you
> can see the hot method names.
>
> I'd suggest to look out for the following things:
>        Are you re-using the ScriptEngine or re-creating it?  You should be 
> re-using it as much as possible, they're expensive to create.
>
>        You could be doing something which is invalidating rules a lot.  For 
> example if you are defining a class in a loop and returning a new instance of 
> a new class every time through Ipy's performance would be noticeably worse.  
> You could see this just by profiling your app in VS and see if there's a lot 
> of time being spend under an Update* method in the DLR which then calls into 
> the IronPython runtime and is spending a lot of time in a Bind* method.  If 
> you see that you can report back the Bind method which is spending all the 
> time and we can discuss the patterns in your code.
>
>        Something else?  Always helpful to run the profiler and see where the 
> time is spent.  You can use the pre-compiling to get more insight about where 
> the time is spent in the Python code in addition to the DLR and IronPython 
> runtimes.
>
>
>> -Original Message-
>> From: ironpython-users-bounces+dinov=microsoft@python.org
>> [mailto:ironpython-users-bounces+dinov=microsoft@python.org] On
>> Behalf Of Jimmy Schementi
>> Sent: Wednesday, May 23, 2012 11:40 AM
>> To: Carles F. Julià
>> Cc: ironpython-users@python.org
>> Subject: Re: [Ironpython-users] Poor performance of a c# - Ironpython
>> application
>>
>> On Wed, May 23, 2012 at 12:44 PM, Carles F. Julià
>>  wrote:
>> >> My guess is that it's .NET's JIT compiler. How do you execute the scripts?
>> >> Are you compiling them and caching the results or re-executing them
>> >> each time?
>> >
>> >
>> > I compile the script once and then I save a python object in a dynamic
>> > variable on c#. Then I access the rest of the python code from there
>> > all the time.
>>
>> To save the most startup time, you should compile all Python code to a DLL
>> using clr.CompileModules, and then load that precompiled assembly.
>> http://ironpython.net/documentation/dotnet/dotnet.html#compiling-
>> python-code-into-an-assembly
>>
>> Ideally you'd do this with all Python code, including the standard library.
>>
>> ~js
>> ___
>> Ironpython-users mailing list
>> Ironpython-users@python.org
>> http://mail.python.org/mailman/listinfo/ironpython-users
>>
>>
>
>
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Set __metaclass__ on .NET type?

[Steve Dower]

If you are loading the file with other Python code (either an `exec`
or `__import__`) you could use something like:

for cls in vars(module):
  if issubclass(cls, Suite):
# do something
  elif issubclass(cls, Task):
# do something

Similar things can be done with a ScriptScope in C# as well. The only
downside is that the set of base classes needs to be known in advance,
but it sounds like you already do. I've found this approach works well
with user-provided scripts and Python-based configuration files.

On Thu, Jun 21, 2012 at 3:53 PM, Dino Viehland  wrote:
> It's not really exposed, but it is "possible" - we do it for ctypes.
>
> For ctypes we use an internal call such as 
> PythonType.SetPythonType(typeof(Suite), new SuiteMetaType());
> where SuiteMetaType is a subclass of PythonType.  If this was a public API 
> you'd do
> that in a static initializer of Suite so it happens before any Suite's are 
> made.
>
> But SetPythonType isn't public...  I could see making it public not being too 
> big
> of a deal - we are all consenting adults and there is a pretty safe way to use
> it.  I'd suggest extending PythonTypeAttribute so the meta-class can be 
> specified
> but that wouldn't allow a whole lot of flexibility in instantiating the 
> meta-class.
>
> I think my biggest concern about this is that these meta-classes bleed across
> runtime instances so you need to be careful about what you do with them, but
> I'm guessing that wouldn't be an issue for most people.
>
> Another way to accomplish this if you're exposing it via a built-in module 
> would
> be to publish a hand-created subtype via the PerformModuleReload method
> doing something like:
>
> dict["Suite"] = PythonType.__new__(,
>    DynamicHelpers.GetPythonTypeFromType(typeof(PythonType)),
>    "Suite",
>    new PythonTuple(new object[] { typeof(Suite) }),
>    {"__metaclass__": new YourSubClassOfPythonType() },
>  );
>
> That'd create a new sub-type of your Suite class which has its meta-class
> set to your meta-class.  The user can then subclass this class rather than
> subclassing your .NET class directly.  It's an extra level of indirection, but
> it also generally gets the per-runtime isolation right.
>
> In general I don't think what you're trying to do is too crazy, at least a 
> more
> elegant solution doesn't really spring to my mind.
>
>
>> -Original Message-
>> From: ironpython-users-bounces+dinov=microsoft@python.org
>> [mailto:ironpython-users-bounces+dinov=microsoft@python.org] On
>> Behalf Of Slide
>> Sent: Wednesday, June 20, 2012 10:22 PM
>> To: ironpython-users@python.org
>> Subject: [Ironpython-users] Set __metaclass__ on .NET type?
>>
>> I am playing around with using IronPython to replace a custom language we
>> use to define tasks and suites of tasks for an in-house automated testing
>> framework. Currently we have something like
>>
>> task FooTask {
>>     cmdline = "...";
>>
>>     file somefile.txt = (.
>> This will have some content, and even supports variables: $VAR1
>>     .)
>> }
>>
>> table SomeTable = {
>>     VAR1
>>     1
>>     2
>>     3
>> }
>>
>> suite SomeSuite {
>>     FooTask(SomeTable);
>> }
>>
>> This would permute FooTask with VAR1 for each row in the table.
>>
>> This is a bit more information than you probably need, but it will give you
>> the feel for what I am trying to do.
>>
>> I was thinking I could reuse the objects that I now create in the parser of
>> the custom language as base types for Python object
>>
>> class FooTask(Task):
>>     def __init__(self, variables):
>>         self.SetCmdLine("")
>>         self.Files.Add("somefile.txt", "This will have some content, and even
>> supports variables: $VAR1")
>>
>> class SomeSuite(Suite):
>>     def __init__(self):
>>         self.AddItem(FooTask() * [ { "VAR1" : "1" }, {"VAR1" : "2" }, { 
>> "VAR1" : "3"
>> } ])
>>
>> I can easily implement __mult__ and other such operations to handle the
>> permutation and other operations I currently support.
>>
>> Now, what I _think_ I need metaclasses for is that when FooTask or
>> SomeSuite is created, I need to be able to add the instance to my symbol
>> table so I can then create the output that I need to.
>>
>> Am I thinking incorrectly about the need for metaclasses? I would like to
>> keep as much of the details as possible away from the users, so I was
>> thinking if I could hook into the object creation, I could add the instance 
>> to
>> my symbol table in the metaclass. For this, I would need to set
>> __metaclass__ on the base classes (Task and Suite), which are .NET objects,
>> is this doable?
>>
>> Am I trying to fit a square peg into a round hole in general?
>>
>> Thanks for reading my ramblings :-)
>>
>> slide
>>
>> --
>> Website: http://earl-of-code.com
>> ___
>> Ironpython-users mailing list
>> Ironpython-users@python.org
>> http://mail.python.org/mailman/listinfo/ironpython-users
>>
>>
>
>
>
> _

Re: [Ironpython-users] Python Tools for Visual Studio 1.5 RC Released

[Steve Dower]

It doesn't currently, but that will probably be a PTVS 2.0 feature.
I'm not sure exactly what's involved yet, but I'd guess that all we
have to do is invoke MSBuild.

You're welcome to code it up yourself and send it in. That will be the
quickest way to get it added (and once you're set up to build, you'll
be able to grab all the new things we commit between releases).

On Wed, Sep 19, 2012 at 2:13 PM, Jeff Hardy  wrote:
> On Wed, Sep 19, 2012 at 1:40 PM, Dino Viehland  wrote:
>> We’re pleased to announce the release of Python Tools for Visual Studio 1.5
>> RC. Python Tools for Visual Studio (PTVS) is an open-source plug-in for
>> Visual Studio which supports programming with the Python language. PTVS
>> supports a broad range of features including CPython/IronPython,
>> Edit/Intellisense/Debug/Profile, Cloud, HPC, IPython, etc. support.
>
> Awesome, I was waiting for VS2012 support so I could switch.
>
> Quick question: if I run 'Build' on a pyproj file from within VS, does
> it run the 'Build' target in the pyproj file? I have some craziness
> that I'd like to do in that case, so it would be fantastic if that's
> how it worked (ditto 'Rebuild' and 'Clean').
>
> - Jeff
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Drag and Drop components of WIndows Forms.

[Steve Dower]

IronPython Studio is well out of date. Its spiritual successor is
Python Tools for Visual Studio (http://pytools.codeplex.com/, which I
work on), but unfortunately we don't have designer support for Windows
Forms.

I guess this is due to a lack of demand, so you can create a request
on our issue tracker, but it's unlikely that it will be added unless
somebody contributes a patch for it. (We're happy to help anyone who's
interested in doing this.)

Cheers,
Steve

On Sat, Oct 20, 2012 at 10:00 PM, Ivanelson Nunes
 wrote:
> The IronPythonStudio been discontinued?
> http://ironpythonstudio.codeplex.com/
>
> Currently there any tool that allows developing Windows Forms applications
> in IronPython using drag and drop?
>
>
> Best Regards!
>
> Ivan - Brazil
>
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] ANN: Python Tools for Visual Studio 1.5

[Steve Dower]

It won't work with the express editions, but you can download the
(free) integrated/isolated shell (two downloads, about ~230MB all up)
and install into that. The only feature that you'll miss out on is
profiling, which requires Premium or higher.

If you meant year-versions, PTVS supports VS2010 and VS2012. There
aren't any feature differences between the two versions, but VS2012 is
generally better all-round (despite the UI changes), so I'd recommend
it if you can get it.

Cheers,
Steve

On Thu, Nov 1, 2012 at 1:18 AM, niki  wrote:
> What is minimal VS version supported?
>
> Thanks,
> Niki
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

[Ironpython-users] Website Updates

[Steve Dower]

I'm not entirely sure who's responsible for updating the website right now, but 
we'd like to get http://www.ironpython.net/tools/ updated (mostly to avoid 
having to update it every time we release).

That page deep links into one of our pre-1.0 releases and a documentation page 
("Walkthrough")that is probably going to be retired. Linking directly to 
http://pytools.codeplex.com/ and http://pytools.codeplex.com/documentation 
would be better.

And feel free to steal any of the screenshots we have up (or I can make an 
IronPython-specific one for you) though I do quite like the one that's already 
there.

Cheers,
Steve

___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Website Updates

[Steve Dower]

http://www.ironpython.net/tools/ is the page. The two "Download" links should 
go straight to http://pytools.codeplex.com/ and the two "Walkthrough" links 
should be removed. The "Documentation" link is still correct.

Thanks,
Steve

From: Vernon D. Cole [mailto:vernondc...@gmail.com] 
Sent: Monday, March 11, 2013 1053
To: Steve Dower
Cc: ironpython-users@python.org; Shahrokh Mortazavi
Subject: Re: [Ironpython-users] Website Updates

I was going to offer to fix that right away, but I cannot seem to find what you 
are talking about. I am probably looking at the wrong web site.  What is the 
URL of the page you need fixed? (and which link is wrong?)
--
Vernon Cole

On Mon, Mar 11, 2013 at 10:03 AM, Steve Dower  wrote:
I'm not entirely sure who's responsible for updating the website right now, but 
we'd like to get http://www.ironpython.net/tools/ updated (mostly to avoid 
having to update it every time we release).
 
That page deep links into one of our pre-1.0 releases and a documentation page 
("Walkthrough")that is probably going to be retired. Linking directly to 
http://pytools.codeplex.com/ and http://pytools.codeplex.com/documentation 
would be better.
 
And feel free to steal any of the screenshots we have up (or I can make an 
IronPython-specific one for you) though I do quite like the one that's already 
there.
 
Cheers,
Steve
 

___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

Re: [Ironpython-users] Install numpy / VS 2010

[Steve Dower]

Anyone who wants to encourage the six developers to fix

https://bitbucket.org/gutworth/six/issues/135/have-a-fallback-for-sys_getframe-usage-in

and/or

https://bitbucket.org/gutworth/six/issues/126/deprecate-exec_

would also help, since this (unused) code is what demands -X:Frames.

Since it'll require a change to pip anyway (as pip vendors six), it'd 
also be a good time to get any other fixes needed into pip. (Though I 
suspect most of the problems though are differences between CPython and 
IronPython, so they probably need to be fixed in IronPython.)


Cheers,
Steve

On 13Jul2016 1143, Slide wrote:

It would be nice if we could generate a pip.bat or something when pip is
installed that would handle the arguments.


On Wed, Jul 13, 2016, 11:41 Vernon D. Cole mailto:vernondc...@gmail.com>> wrote:

The script in the blog does work -- if run from the IronPython
directory on a CMD screen which is run as an administrator.  (This
is using a virgin Windows 10).
> "C:\Program Files\IronPython 2.7>ipy -X:Frames -m ensurepip"

DO NOT follow that up with an "install --upgrade pip"!
The later version of pip will not run as a module, and when run as a
command gives "ImportError: No module named urllib"

We have work to do, guys.


On Wed, Jul 13, 2016 at 11:26 AM, Slide mailto:slide.o@gmail.com>> wrote:

FYI, the blog has been moved to ironpython.net
 from blogger. The link to the article in
question is
here: http://ironpython.net/blog/2014/12/07/pip-in-ironpython-275.html

I am working on a redirect on blogger to the new location. This
is to allow blog posting from community members as PR on github
(https://github.com/IronLanguages/ironpython.net)

Thanks,

slide

On Wed, Jul 13, 2016 at 10:00 AM Vernon D. Cole
mailto:vernondc...@gmail.com>> wrote:

Lawrence:
  Your question has two answers.

1) IronPython will run pip. You need to use a longer command
line to prevent PIP from crashing when it calls _getframe.
(I thought that PIP had been patched to prevent that, but I
can't find the reference anymore.)  Please refer to the
instructions at
http://blog.ironpython.net/2014/12/pip-in-ironpython-275.html

2) Numpy will not run on IronPython.  There has been a good
deal of discussion on this mail list about how to fix that.
Helpers would be welcome.


On Wed, Jul 13, 2016 at 3:43 AM, Lawrence Barwick
mailto:lawrence.barw...@bainbridgepartners.com>> wrote:

Hi,

__ __

I am unable to install ANY packages in VS 2010 with
IronPython.

__ __

This is what I get when right-clicking on Environment
and trying to install numpy via pip

__ __

Installing 'numpy'

Unhandled exception:

Traceback (most recent call last):

  File "C:\Program Files (x86)\IronPython
2.7\Lib\runpy.py", line 170, in run_module

  File "C:\Program Files (x86)\IronPython
2.7\Lib\runpy.py", line 101, in _get_module_details

  File "C:\Program Files (x86)\IronPython
2.7\Lib\pkgutil.py", line 456, in get_loader

  File "C:\Program Files (x86)\IronPython
2.7\Lib\pkgutil.py", line 466, in find_loader

  File "C:\Program Files (x86)\IronPython
2.7\Lib\pkgutil.py", line 422, in iter_importers

  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\pip\__init__.py", line 13, in


  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\pip\exceptions.py", line 6, in


  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\pip\_vendor\six.py", line 701, in


  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\pip\_vendor\six.py", line 692, in
exec_

  File "C:\Program Files (x86)\IronPython
2.7\Lib\runpy.py", line 109, in _get_module_details

AttributeError: 'module' object has no attribute
'_getframe'

__ __

'numpy' failed to install. Exit code: 1

__ __

Bainbridge Partners LLP is authorised and regulated by
the Financial Conduct Authority to provide investment
services to qualified investors.  Bainbridge Partners
LLP is registered in England, no. OC341436,