[IronPython] How can IronPython access a public static value defined in C#?
Consider this C# code:
public static class Graphics {
public static Color white = new Color(255, 255, 255);
}
I can compile and import this from IronPython:
import clr
clr.AddReference(Graphics)
import Graphics
Graphics.white
Color 255,255,255
But I can't:
import clr
clr.AddReference(Graphics)
from Graphics import *
white
Traceback (most recent call last):
File /home/dblank/Calico/src/engine.py, line 159, in execute
source.Execute(self.manager.scope)
File string, line 1, in module
type 'exceptions.NameError': name 'white' is not defined
Is there something I can do to make white accessible with from ... import *?
Thanks for any pointers,
-Doug
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] matplotlib anyone?
On Mon, May 16, 2011 at 4:20 PM, Chad Brockman cha...@slb.com wrote: Yes, unfortunately IronClad appears to be all but dead. I’ve looked at Sho – but the charts are just the 2d MSCharts for .Net (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=130f7986-bf49-4fe5-9ca8-910ae6ea442c) I was hoping support for this might be part of the NumPy / SciPy port being done by Enthought - http://pytools.codeplex.com/wikipage?title=NumPy%20and%20SciPy%20for%20.Net Thanks -- Chad We will be working on either building or bundling a cross-platform, managed .DLL for use in .NET/Mono scripting languages over the next couple of years. Combined with .NET languages, we hope that it could be a replacement for scipy/matplotlib. We are just now in the planning stages; colleagues welcomed! -Doug --- I was also looking into this for an application im developing. You can try it with IronClad. I wish there was a fully managed version for IronPython. Sho seems to have a graphing library similar to matplotlob. You can check that our and see On Mon, May 16, 2011 at 2:39 AM, Thomas Heller theller at ctypes.org wrote: Brian Curtin brian.curtin at gmail.com schrieb: On Sun, May 15, 2011 at 12:03, Chad Brockman chadbr at slb.com wrote: Is anyone aware of any efforts to allow usage of matplotlib from IronPython? http://matplotlib.sourceforge.net/ I've never heard of any. I don't think any of the backends (tk, wx, Qt) work with IronPython, and they have a bunch of C extensions that would have to be handled as well. ___ 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] Extending Gtk.TextView
Does anyone have an idea what this would mean, or how to fix it? import Gtk class MyTextView(Gtk.TextView): ... pass mtv = MyTextView() (pyjama:611): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.28.6/./gobject/gsignal.c:1549: signal set_scroll_adjustments already exists in the `GtkTextView' class ancestry -Doug ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] AttributeError : System.Drawing.Graphics is read-only
On Mon, Apr 18, 2011 at 7:56 AM, NikoVFR vfr.n...@hotmail.fr wrote: Hello everybody... first i apologize for my bad english... i did not practice for a very long time... A strange problem in a ironpython app, done with Sharpdevelop... I created a form, without borders, captions, icon, just a simple square to draw... When I try to draw from my OnPaint Function, IronPy answers me : Exception.AttributeError : attribute 'Graphics' of 'namespace#' object is read-only That usually means that you have misspelled an attribute. For example, if you say Gtk.Wibbow instead of Gtk.Window, you'll get that error. (It is actually a bad error message in that you are only looking up a value, not creating one; is that only a Mono-only issue I wonder?) As Jimmy says, we'd need to see the code to say more. -Doug Thanks for helping me, i really can't find any solution here... -- View this message in context: http://old.nabble.com/AttributeError-%3A-System.Drawing.Graphics-is-%22read-only%22-tp31419737p31419737.html Sent from the IronPython mailing list archive at Nabble.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] Building IronPython/IronRuby for Mono? Yes!
On Fri, Mar 25, 2011 at 3:02 PM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Mar 25, 2011 at 12:46 PM, Doug Blank doug.bl...@gmail.com 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. Thanks! BTW, IronRuby also builds under Mono 2.10 with the 2.0 framework and so runs under Mono 2.6.7, so we have a complete DLR set for Mono. xbuild Solutions/Ruby.sln /p:Configuration=v2Release I've also been updating the wiki to keep it up to date: http://ironpython.codeplex.com/wikipage?title=IronPython%20on%20Mono Let me know if you have suggestions, or corrections. -Doug - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython and XML Parsing
As the the original issue, I couldn't get the FePy XML parser to work (nor any variation), so gave up, and went with a stand-alone XMPP dll that does it all. It would be most excellent to get a expat module working. To Vernon's point: On Wed, Apr 6, 2011 at 1:58 PM, Vernon Cole vernondc...@gmail.com wrote: I was thinking of an actual .deb file, which will put everything in the right place, hook up menus and whatnot, like the Windows installer does. I thought I'd try that after I finally manage to create a .NET 2.0 build which works. [I re-built my Ubuntu box last weekend so that I can start over. My earlier efforts resulted in killing my old Ubuntu installation, and the openSUSE I replaced it with was an interesting experiment, but not something I can use on a day-by-day basis.] I want the next guy to have less trouble than me. I was thinking of using fepy to perhaps collect lots of optional modules -- like the db-api modules which are already there -- in one place so they are easy to find and load. PyPi has lots of modules, but how many of them will run on IronPython? The only one I am sure about is the one I support myself. I think a modest core of extra (non-standard-library) modules would be nice. I definitely do want to have the packaging tools working, too, but I would like to not have to go hunting and experimenting. I'd rather have all of the old FePy-like support here. I don't see a reason we need to divide Windows IronPython from Linux etc IronPython, right? My first thought was to package everything EXCEPT the Python installer, just use the distro installer (on Linux) or the .msi installer, and then add the extras from fepy. But I started to change my mind at the announcement that there would not be a .NET 2.0 release of IPy 2.7. Perhaps not having a 2.7 which runs on my distro is making me a bit crazy? 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. -Doug -- Vernon On Wed, Apr 6, 2011 at 11:20 AM, Jeff Hardy jdha...@gmail.com wrote: On Wed, Apr 6, 2011 at 11:07 AM, Vernon Cole vernondc...@gmail.com 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Writing cross-language libraries that appear native
On Tue, Apr 5, 2011 at 3:05 AM, Markus Schaber
m.scha...@3s-software.com wrote:
Hi, Doug,
I it won't be possible to make it feel naturally with every language,
simply because the languages have very different naming conventions (C#
mandates CamelCase, Python prefers words_with_underscores, ...) and
programming paradigms.
It is true that each language has conventions, and also true that some
languages have multiple conventions (for example, there are CamelCase
and underscore Python programmers). But there are some options that
just aren't possible. For example, it was not even possible to access
a lowercased class name from IronRuby (at least when I tried a while
back). My goal was to document that kind of issue. Also, the naming
convention isn't so important (to us) as is a natural way of passing
parameters and getting back results.
But on the other hand, you should keep in mind that .NET was designed as a
multi-paradigm environment, and that all those Languages were implemented
with this in mind.
Well, not all .NET languages are implemented by Microsoft, and many
follow their own conventions. I'm trying to come up with some
guidelines for writing good libraries that work across a wide spectrum
(from Boo to F#).
Most of the dynamic languages have very clever parameter resolution and
automatic casting mechanisms implemented, as they offer easy access to the
whole .NET standard library - this will automatically apply to your
interface, too. E. G. any python list and tuple can be passed to a function
taking a IEnumerableFoo, python will create an auto-casting enumerator, and
will throw when the sequence contains elements not compatible to Foo.
Yes, the Iron* languages are excellent in this regard. I'm hoping that
more languages will adopt that autocasting code, if not more of the
DLR.
Nevertheless, my concrete points of advice are:
- I think the most important thing is that you make a simple, clearly
structured API.
- Be generous but exact in what you accept. For example if you need a
sequence of Foo as parameter, accept IEnumerableFoo.
* No need to use IEnumerable and cast yourself - more Code to type, the
dynamic language binding will auto-cast for you, and the statically typed
languages like C# and F# profit from the stricter declaration.
* Accepting IListFoo or ICollectionFoo is too strict for the main
method, but if your algorithm can profit from indexing or knowing the size,
you may provide them as optimized overloads.
- Adhere to the coding standards / naming conventions in the language you use
to implement.
- Take care that all your functionality is exposed in CLS conformant ways.
(IMHO, it is okay to provide optimized non-CLS conformant alternative ways of
access. One example is that you should provide access methods for all
overloaded operators. Browse the Web and MSDN for CLS conformance, you'll
find lots of guidelines.)
If you could give an example guideline url, that would be useful...
maybe I'm using bad search terms.
- After drafting your interface (or implementing the first alpha), ask users
of the target languages for their advice, or implement a test application in
all of the languages.
Yes, I'm writing examples in all of the .NET languages and libraries
that we [1] support [2].
(I personally don't have any experience with IronRuby, and simply assumed
that they use similar mechanisms like IronPython, so take my advice with a
grain of salt.)
IronRuby does some cleaver things such as renaming CamelCase items to
camel_case. But most languages don't.
I'll eventually document all this on a website (can I use your
suggestions?) This may be beyond the scope of the IronPython website,
though.
-Doug
[1] http://pyjamaproject.org/
[2] http://svn.cs.brynmawr.edu/viewvc/Pyjama/trunk/examples/
Regards,
Markus
-Ursprüngliche Nachricht-
Von: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] Im Auftrag von Doug Blank
Gesendet: Montag, 4. April 2011 17:25
An: Discussion of IronPython
Betreff: [IronPython] Writing cross-language libraries that appear native
I'm working on writing C# libraries which can be imported by a variety of
.NET languages, DLR and otherwise, which appear native to the language
importing them.
For example, writing a C# function that can be used naturally in
IronPython as if it were written in Python, IronRuby as if it were written
in Ruby, and F# as if it were written in F#, etc.
I've encountered some gotchas that I thought I'd share, and looking for
any other points of advice in writing cross-language libraries.
1. IronRuby strings aren't really strings, so you need to pass them in as
an object, and call .ToString().
public static string expects_string(object val) {
return val.ToString();
}
2. F# 2.0 doesn't seem to automatically convert a type to the associated
nullable type, so avoid nullable types as parameters
[IronPython] Writing cross-language libraries that appear native
I'm working on writing C# libraries which can be imported by a variety
of .NET languages, DLR and otherwise, which appear native to the
language importing them.
For example, writing a C# function that can be used naturally in
IronPython as if it were written in Python, IronRuby as if it were
written in Ruby, and F# as if it were written in F#, etc.
I've encountered some gotchas that I thought I'd share, and looking
for any other points of advice in writing cross-language libraries.
1. IronRuby strings aren't really strings, so you need to pass them in
as an object, and call .ToString().
public static string expects_string(object val) {
return val.ToString();
}
2. F# 2.0 doesn't seem to automatically convert a type to the
associated nullable type, so avoid nullable types as parameters.
// AVOID:
public static double? expects_nullable(double? var1=null) {
return var1;
}
// BETTER:
public static double? expects_nullable() {
return null;
}
public static double expects_nullable(double var1) {
return var1;
}
3. IronPython and IronRuby lists and dictionaries implement IList and
IDictionary, so no problem with those.
public static IDictionaryobject,object make_dict(object val) {
if (val as IDictionaryobject,object != null) {
return ((IDictionaryobject,object)val);
} else
throw new System.ArgumentException(object is not a dictionary);
}
public static IListobject make_list(object val) {
if (val as IListobject != null) {
return ((IListobject)val);
} else
throw new System.ArgumentException(object is not a list);
}
Any other suggestions?
-Doug
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Writing cross-language libraries that appear native
On Mon, Apr 4, 2011 at 11:52 AM, Tomas Matousek
tomas.matou...@microsoft.com wrote:
Re: 1.
MutableString is convertible to String, so why would you need an object
parameter?
Do you mean that one could write:
public static string expects_string(MutableString val) {
return (val as String);
}
I wrote:
public static string expects_string(object val) {
return val.ToString();
}
because that would work for all languages, and you could pass in an
IronPython or F# string it it would work just as well. Or did you mean
something else?
-Doug
Tomas
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Doug Blank
Sent: Monday, April 04, 2011 8:25 AM
To: Discussion of IronPython
Subject: [IronPython] Writing cross-language libraries that appear native
I'm working on writing C# libraries which can be imported by a variety of
.NET languages, DLR and otherwise, which appear native to the language
importing them.
For example, writing a C# function that can be used naturally in IronPython
as if it were written in Python, IronRuby as if it were written in Ruby, and
F# as if it were written in F#, etc.
I've encountered some gotchas that I thought I'd share, and looking for any
other points of advice in writing cross-language libraries.
1. IronRuby strings aren't really strings, so you need to pass them in as an
object, and call .ToString().
public static string expects_string(object val) {
return val.ToString();
}
2. F# 2.0 doesn't seem to automatically convert a type to the associated
nullable type, so avoid nullable types as parameters.
// AVOID:
public static double? expects_nullable(double? var1=null) {
return var1;
}
// BETTER:
public static double? expects_nullable() {
return null;
}
public static double expects_nullable(double var1) {
return var1;
}
3. IronPython and IronRuby lists and dictionaries implement IList and
IDictionary, so no problem with those.
public static IDictionaryobject,object make_dict(object val) {
if (val as IDictionaryobject,object != null) {
return ((IDictionaryobject,object)val);
} else
throw new System.ArgumentException(object is not a dictionary);
}
public static IListobject make_list(object val) {
if (val as IListobject != null) {
return ((IListobject)val);
} else
throw new System.ArgumentException(object is not a list);
}
Any other suggestions?
-Doug
___
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] Writing cross-language libraries that appear native
On Mon, Apr 4, 2011 at 12:54 PM, Jimmy Schementi jscheme...@gmail.com wrote:
Tomas means you can write this:
public static string ExpectsString(string val) {
return val;
}
And call it from Ruby with a Ruby string:
expects_string Foo
Yes, indeed, that works fine. Thanks! So, the DLR languages all behave
properly with all types, even with nullable and default values ---if
you name your classes correctly. Another point I discovered was that I
had to name my outer class with upper case letters, or else IronRuby
couldn't access it.
Any other gotchas or time savers for non-DLR languages? (I wish the
DLR group could help the F# group... they don't even have an eval,
except for running the entire fsi.exe in a subprocess... wouldn't that
be nice if they used a DLR environment...)
-Doug
~Jimmy
On Apr 4, 2011, at 12:21 PM, Doug Blank doug.bl...@gmail.com wrote:
On Mon, Apr 4, 2011 at 11:52 AM, Tomas Matousek
tomas.matou...@microsoft.com wrote:
Re: 1.
MutableString is convertible to String, so why would you need an object
parameter?
Do you mean that one could write:
public static string expects_string(MutableString val) {
return (val as String);
}
I wrote:
public static string expects_string(object val) {
return val.ToString();
}
because that would work for all languages, and you could pass in an
IronPython or F# string it it would work just as well. Or did you mean
something else?
-Doug
Tomas
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Doug Blank
Sent: Monday, April 04, 2011 8:25 AM
To: Discussion of IronPython
Subject: [IronPython] Writing cross-language libraries that appear native
I'm working on writing C# libraries which can be imported by a variety of
.NET languages, DLR and otherwise, which appear native to the language
importing them.
For example, writing a C# function that can be used naturally in IronPython
as if it were written in Python, IronRuby as if it were written in Ruby,
and F# as if it were written in F#, etc.
I've encountered some gotchas that I thought I'd share, and looking for any
other points of advice in writing cross-language libraries.
1. IronRuby strings aren't really strings, so you need to pass them in as
an object, and call .ToString().
public static string expects_string(object val) {
return val.ToString();
}
2. F# 2.0 doesn't seem to automatically convert a type to the associated
nullable type, so avoid nullable types as parameters.
// AVOID:
public static double? expects_nullable(double? var1=null) {
return var1;
}
// BETTER:
public static double? expects_nullable() {
return null;
}
public static double expects_nullable(double var1) {
return var1;
}
3. IronPython and IronRuby lists and dictionaries implement IList and
IDictionary, so no problem with those.
public static IDictionaryobject,object make_dict(object val) {
if (val as IDictionaryobject,object != null) {
return ((IDictionaryobject,object)val);
} else
throw new System.ArgumentException(object is not a dictionary);
}
public static IListobject make_list(object val) {
if (val as IListobject != null) {
return ((IListobject)val);
} else
throw new System.ArgumentException(object is not a list);
}
Any other suggestions?
-Doug
___
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] [Code Review] Custom PAL fixes
On Thu, Mar 31, 2011 at 9:05 PM, Jimmy Schementi ji...@schementi.com wrote: By the way, is it about time to split this list into a development and users list, or you all don't mind seeing these type of mails? Many of the people subscribed want to get any insight into the DLR languages as they can. But I have noticed that there are some user-type questions that get no responses here. It is easy to join two mailing lists, and if splitting would allow user-questions to get more attention, then that would be a good thing. -Doug ~Jimmy ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!
On Thu, Mar 24, 2011 at 1:30 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: It seems that we just need to disable XML warning in Microsoft.System.Core project. Ok. If you can provide a bit more information about this, I'll take a stab, or report an issue in the tracker. It sounds like support for IronPython 2.7 using the 2.0 framework under Mono is getting close! -Doug Tomas ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!
On Fri, Mar 25, 2011 at 12:16 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: It's fixed - a trivial change: https://github.com/IronLanguages/main/commit/a8d9bc96aefcdb30bfd93a091b60ffb8fa4a8e4a 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. Three easy steps: 1) git clone https://github.com/IronLanguages/main.git IronPython 2) cd IronPython 3) xbuild Solutions/IronPython.Mono.sln /p:Configuration=v2Release Thanks for this work, Tomas (and everyone else, too)! -Doug Tomas ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython on Mono, and web updates
On Wed, Mar 23, 2011 at 11:05 AM, Jeff Hardy jdha...@gmail.com wrote: On Wed, Mar 23, 2011 at 7:13 AM, Doug Blank doug.bl...@gmail.com 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. Yes, they do. I've begun to add some hopefully helpful notes re Mono to: http://ironpython.codeplex.com/ some .NET/Mono sections to: http://ironpython.codeplex.com/wikipage?title=Respository%20InstructionsreferringTitle=Home and a new page: http://ironpython.codeplex.com/wikipage?title=IronPython%20on%20Mono Please give feedback or feel free to refine. BTW, what is the relationship between the codeplex site, ironpython.net, and ironpython.info? It seems like information/files are spread across them. Can some consolidation be done? Or are there guidelines about what goes where? 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. I made a note about that on the website, and hopefully Tomas can make that irrelevant soon. -Doug - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] State of Moonlight with IronPython?
Anyone know what the state of being able to view Moonlight apps in the browser with DLR languages? Or actually, what the state of Moonlight is generally? None of the examples off of the IronPython page: http://ironpython.net/browser/examples.html work under my Ubuntu 64-bit 10.10 with Firefox 3.6.15, with Moonlight 3.99.0.2. Known limitations, or reportable? -Doug ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!
On Thu, Mar 24, 2011 at 12:30 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: Done. Thanks! Having some issues under Mono 2.10 with Microsoft.Scripting.Ast.Expression, and System.Runtime.CompilerServices. Here is my output, with a fresh IronPython git main. Any ideas? Also, if anyone builds IronPython 2.7 for .NET 2.0 under Windows and wants to make the binaries available, that would be useful to see if those work on Mono as well. -Doug $ xbuild Solutions/IronPython.Mono.sln /p:Configuration=v2Release XBuild Engine Version 2.10.1.0 Mono, Version 2.10.1.0 Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011. Build started 3/24/2011 12:49:58 PM. __ /tmp/main/Solutions/IronPython.Mono.sln: warning : Project file /tmp/main/Hosts/SilverLight/Microsoft.Scripting.SilverLight/Microsoft.Scripting.Silverlight.csproj referenced in the solution file, not found. Ignoring. /tmp/main/Solutions/IronPython.Mono.sln: warning : Project file /tmp/main/Hosts/SilverLight/Chiron/Chiron.csproj referenced in the solution file, not found. Ignoring. Project /tmp/main/Solutions/IronPython.Mono.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration v2Release|Any CPU. Target Build: Project /tmp/main/Runtime/Microsoft.Scripting.Metadata/Microsoft.Scripting.Metadata.csproj (default target(s)): Target PrepareForBuild: Configuration: v2Release Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Skipping target CoreCompile because its outputs are up-to-date. Done building project /tmp/main/Runtime/Microsoft.Scripting.Metadata/Microsoft.Scripting.Metadata.csproj. Project /tmp/main/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.Core.csproj (default target(s)): Target PrepareForBuild: Configuration: v2Release Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/bin/gmcs execution started with arguments: /noconfig /debug:full /keyfile:/tmp/main/Solutions//Key.snk /optimize+ /out:obj/v2Release/Microsoft.Scripting.Core.dll Actions/CallInfo.cs Actions/CallSiteOps.cs Actions/IInvokeOnGetBinder.cs Actions/InvokeMemberBinder.cs Actions/BinaryOperationBinder.cs Actions/CallSite.cs Actions/CallSiteBinder.cs Actions/CallSiteHelpers.cs Actions/ConvertBinder.cs Actions/DeleteIndexBinder.cs Actions/DynamicObject.cs Actions/ExpandoObject.cs Actions/ExpandoClass.cs Actions/GetIndexBinder.cs Actions/CreateInstanceBinder.cs Actions/DeleteMemberBinder.cs Actions/GetMemberBinder.cs Actions/IDynamicMetaObjectProvider.cs Actions/InvokeBinder.cs Actions/DynamicMetaObject.cs Actions/DynamicMetaObjectBinder.cs Actions/BindingRestrictions.cs Actions/RuleCache.cs Actions/SetIndexBinder.cs Actions/SetMemberBinder.cs Ast/Expression.DebuggerProxy.cs Ast/IArgumentProvider.cs Ast/ListArgumentProvider.cs Actions/UnaryOperationBinder.cs Ast/ExpressionStringBuilder.cs Compiler/BoundConstants.cs Ast/DebugInfoExpression.cs Ast/SymbolDocumentInfo.cs Compiler/DelegateHelpers.cs Compiler/DelegateHelpers.Generated.cs Ast/GotoExpression.cs Compiler/LabelInfo.cs Compiler/AnalyzedTree.cs Compiler/OffsetTrackingILGenerator.cs Compiler/RuntimeVariableList.cs Actions/UpdateDelegates.Generated.cs Ast/DynamicExpression.cs Ast/BinaryExpression.cs Ast/BlockExpression.cs Ast/CatchBlock.cs Ast/ConditionalExpression.cs Ast/ConstantExpression.cs Ast/DefaultExpression.cs Ast/ElementInit.cs Ast/Expression.cs Ast/ExpressionType.cs Ast/IndexExpression.cs Ast/InvocationExpression.cs Ast/LabelTarget.cs Ast/LabelExpression.cs Ast/LambdaExpression.cs Ast/ListInitExpression.cs Ast/RuntimeVariablesExpression.cs Ast/LoopExpression.cs Ast/MemberAssignment.cs Ast/MemberBinding.cs Ast/MemberExpression.cs Ast/MemberInitExpression.cs Ast/MemberListBinding.cs Ast/MemberMemberBinding.cs Ast/MethodCallExpression.cs Ast/NewArrayExpression.cs Ast/NewExpression.cs Ast/ParameterExpression.cs Ast/SwitchCase.cs Ast/SwitchExpression.cs Ast/TryExpression.cs Ast/TypeBinaryExpression.cs Ast/TypeUtils.cs Ast/UnaryExpression.cs Compiler/Closure.cs Compiler/CompilerScope.Storage.cs Compiler/CompilerScope.cs Compiler/ConstantCheck.cs Compiler/ExpressionQuoter.cs Ast/ExpressionVisitor.cs Ast/DebugViewWriter.cs Compiler/HoistedLocals.cs Compiler/KeyedQueue.cs Compiler/LambdaCompiler.Address.cs Compiler/LambdaCompiler.Binary.cs Compiler/LambdaCompiler.ControlFlow.cs Compiler/LambdaCompiler.Expressions.cs
Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!
On Tue, Mar 22, 2011 at 1:30 PM, Jeff Hardy jdha...@gmail.com wrote: On Tue, Mar 22, 2011 at 11:03 AM, Doug Blank doug.bl...@gmail.com 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. I have successfully built IronPython 2.7 on Mono 2.10 on Ubuntu 10.10 for .NET 4.0. Details below. But I'd like to try for .NET 2.0, to see if it will run under Mono 2.6.7, so if someone could send me a hint on the MSBuild configuration magic, that would be helpful. Of course, I will be using xbuild. To build IronPython under Mono 2.10: 0) Prereqs (I started from a clean Ubuntu 10.10): sudo apt-get install git subversion gcc emacs libmono-corlib2.0-cil libmono-system2.0-cil libmono-i18n2.0-cil libmono-system-runtime2.0-cil libmono-winforms2.0-cil libmono-microsoft-visualbasic8.0-cil nant mono-xbuild automake libtool gettext gnome-common g++ bison 1) Get Mono 2.10 as per: http://mono-project.com/Compiling_Mono_From_Git a) Switched to 2.10 b) Installed in /opt (--prefix=/opt) 2) Allow multiple versions of Mono: http://apebox.org/wordpress/linux/370/ 3) Download IronPython: https://download.github.com/IronLanguages-main-ipy-2.7-0-g4fb2552.zip or https://download.github.com/IronLanguages-main-ipy-2.7-7-g4e7a828.zip or git clone https://github.com/IronLanguages/main.git into ./IronPython/ 4) Edit IronPython/Solutions/Dlr.sln Removed anything that said test and other parts that aren't needed. (One test had a file that Mono wouldn't read the .il code correctly (./Test/ClrAssembly/Src/typeforwarder2.il) and some filenames in csproj files that had the wrong case, which doesn't work too well on a case-sensitive file system. I started to fix those, but left that for now). 5) Delete IronPython/bin/Debug/*.dll 6) Build it: cd IronPython/Solutions/ xbuild Dlr.sln xbuild IronPython.sln 7) Test: $cd ../bin/Debug/ $ mono ipy.exe IronPython 2.7 DEBUG (2.7.0.40) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. 1 + 1 2 ^d It is still in gray colors, but that works. 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? 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. I will add this information to the wiki so that people can do exactly that. -Doug - 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!
On Wed, Mar 23, 2011 at 12:13 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: However, it appears that building the v2... targets doesn't work right now This should be fixed now. Do we need to change the IronPython.Mono.sln too? Looking through Solutions/IronPython.Mono.sln, I only see Debug and Release configurations (and those both work great). I'm new to git, so maybe I have the wrong code, but I'm getting an error on v2Release and v2Debug: # yesterday: $ git clone https://github.com/IronLanguages/main.git $ cd main # today: $ git pull remote: Counting objects: 27, done. remote: Compressing objects: 100% (14/14), done. remote: Total 14 (delta 11), reused 0 (delta 0) Unpacking objects: 100% (14/14), done. From https://github.com/IronLanguages/main 4e7a828..a04ffe8 master - origin/master Updating 4e7a828..a04ffe8 Fast-forward .../IronPython/IronPython/Runtime/PythonTuple.cs |2 +- Runtime/Microsoft.Dynamic/Math/BigIntegerV2.cs | 16 +++- Runtime/Microsoft.Dynamic/Math/BigIntegerV4.cs | 10 +++--- Runtime/Microsoft.Dynamic/Utils/MathUtils.cs | 12 ++-- 4 files changed, 29 insertions(+), 11 deletions(-) $ git status # On branch master nothing to commit (working directory clean) $ xbuild Solutions/IronPython.Mono.sln /p:Configuration=v2Release ... Project /tmp/main/Solutions/IronPython.Mono.sln (default target(s)): Target ValidateSolutionConfiguration: /tmp/main/Solutions/IronPython.Mono.sln: error : Invalid solution configuration and platform: v2Release|Any CPU. Task Error execution -- FAILED Done building target ValidateSolutionConfiguration in project /tmp/main/Solutions/IronPython.Mono.sln.-- FAILED Done building project /tmp/main/Solutions/IronPython.Mono.sln.-- FAILED Build FAILED. -Doug Tomas -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Wednesday, March 23, 2011 8:05 AM To: Doug Blank Cc: Discussion of IronPython Subject: Re: [IronPython] Building IronPython/IronRuby for Mono? Yes! On Wed, Mar 23, 2011 at 7:13 AM, Doug Blank doug.bl...@gmail.com 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython/IronRuby for Mono? Yes!
On Wed, Mar 23, 2011 at 6:26 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: I see, I guess I forgot to add these configs to IronPython.Mono.sln. But they shoud certainly be there. Ok. I tried but couldn't guess my way to a working system. Can you add them, or should an issue be filed? Thanks! -Doug Tomas ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Building IronPython/IronRuby for Mono?
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? 2) I tried the zipped binaries on Mono 2.6.7 under Ubuntu 10.10, but that doesn't look like it is supported: $ mono ipy.exe WARNING: The runtime version supported by this application is unavailable. Using default runtime: v1.1.4322 ** (ipy.exe:11466): WARNING **: Missing method System.Environment::SetEnvironmentVariable(string,string) in assembly /usr/lib/mono/1.0/mscorlib.dll, referenced in assembly /home/dblank/Desktop/IronPython-2.7/ipy.exe Unhandled Exception: System.MissingMethodException: Method not found: 'System.Environment.SetEnvironmentVariable'. 3) Looked in Source Code; found a zip, but it is 180 MB. Is that all of svn? How do I get just 2.7? 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? 5) Can I use Mono 2.6.7 to build IronPython 2.7? How? I tried xbuild in the Solutions dir, but only errors. Thanks for any help on building (or getting) IronPython2.7 for Mono. -Doug [1] http://PyjamaProject.org/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython/IronRuby for Mono?
On Tue, Mar 22, 2011 at 9:29 AM, Markus Schaber m.scha...@3s-software.com wrote: Hi, Doug, Doug Blank wrote: 2) I tried the zipped binaries on Mono 2.6.7 under Ubuntu 10.10, but that doesn't look like it is supported: IronPython 2.7 and newer seem to need at least .NET 4.0, which needs at least Mono 2.8. 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. -Doug Best regards Markus Schaber ___ 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] Building IronPython/IronRuby for Mono?
On Tue, Mar 22, 2011 at 11:03 AM, Jeff Hardy jdha...@gmail.com wrote: On Tue, Mar 22, 2011 at 7:33 AM, Doug Blank doug.bl...@gmail.com 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. 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%20InstructionsreferringTitle=Home http://ironpython.codeplex.com/wikipage?title=Contributing%20to%20IronPythonreferringTitle=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. -Doug - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building IronPython/IronRuby for Mono?
On Tue, Mar 22, 2011 at 11:55 AM, Vernon Cole vernondc...@gmail.com wrote: On Tue, Mar 22, 2011 at 8:14 AM, Markus Schaber m.scha...@3s-software.com wrote: Doug Blank wrote: IronPython 2.7 and newer seem to need at least .NET 4.0, which needs at least Mono 2.8. 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. As far as I can see, you need .NET 4 / Mono 2.8 for both compiling and running. [...] IronPython 2.6.2 is delivered in two versions, one for .NET 4 and the other one for .NET 2 (but using some C# 3 language features). Markus Schaber Thanks, Vernon, for this useful information. Some additional comments below: Correct! IronPython 2.6.2 will work ALMOST correctly on Ubuntu 10.10, IF you use the binary which is linked for .NET 2.0. The error I experienced is that the black typeface on the default Gnome Terminal (with a white background) turns to light grey when IPy starts. If you switch Gnome Terminal to the black background, all is well. I assume that change happened after 2.6.b2. 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? The version of mono is a more interesting story. (Bear with me, I spent a lot of time last week learning this.) Ubuntu has made the corporate decision to go with mono as part of their core. Ubuntu will not work without mono, and about 40 supported applications (they tell me) use mono. This is great news for the mono people, IMHO. But it comes with a cost. Mono is created on a Redhat-like system, SUSE. This is easy to understand, since the core group lives at Novell, the sponsor of SUSE. It seems that Redhat/SUSE have diverged enough from Debian that a significant amount of patching is required to make the stock (SUSE) release of mono work correctly on Debian. andrew recently was talking about RPM build scripts on this list, but I never heard a follow-up regarding if that information was being shared: On Wed, Feb 9, 2011 at 3:41 PM, Andrew Jorgensen and...@jorgensenfamily.us wrote: Hello Folks, First let me thank you for making IronPython easy to compile on Mono. I'm the release manager for the Mono Project at Novell and I'm currently working on packaging IronPython and IronRuby for openSUSE (also to be included in the Mono Mac framework package). Where I've run into trouble is the stdlibs for both. I can see that the -Bin.zip contains a Lib directory with various standard libraries in it but I don't see how I can reliably and repeatably get that exact content into my RPM packages (short of including the -Bin.zip in the build). Is there a script of some sort that takes the appropriate files from the correct source and puts them where I need them (the script used to build the -Bin.zip perhaps?) +1 Happy Happy Joy Joy I was wondering if there is any effort to document (or publish) this build process on Linux so that other distributions can also build these packages for distribution? Perhaps that is a way forward? The Debian maintainers apply their patches to the LTS [long term support] version of mono, which at this point is 2.6.3. One of the Debian mono maintainers has supplied a patched 2.10 mono as a PPA on launchpad, but he only supports LTS versions of Ubuntu, which 10.10 is not. Therefore, the newest (i.e. .NET 4) software will not run on the newest Ubuntu. A very frustrating paradox. FYI, the latest LTS Ubuntu is 10.04. Which means (I think) that the next LTS Ubuntu is due in 2012 (12.04). (Vernon corrected in separate email the point that Ubuntu is shipping with Mono 2.6.7 as the current version.) I need a solution for general installs. Perhaps a stand-alone Mono 2.10 install will work, if I can't build IronPython 2.7 on Mono 2.10, and then run with Mono 2.6.7... -Doug I received several suggestions about how to get around this problem, most of them involving virtual machines, or sandboxes. Since Redhat and SUSE are not as heavily invested in mono, they run more current versions. The latest suggestion, which I must rebuild my Linux partition before I can test, is this: v v v v v v v from Christopher James Halse Rogers r...@ubuntu.com sender-time Sent at 7:24 PM (GMT+11:00). Current time there: 2:27 AM. ✆ to Vernon Cole vernondc...@gmail.com cc ubuntu-devel-disc...@lists.ubuntu.com subject Re: IronPython and Mono are very old. How can we get an update? [...snip...] Hm. I should have linked http://apebox.org/wordpress/linux/370/ which is a description of how to do a parallel mono install in a way that works
Re: [IronPython] Building IronPython/IronRuby for Mono?
On Tue, Mar 22, 2011 at 1:41 PM, Vernon Cole vernondc...@gmail.com wrote: On Tue, Mar 22, 2011 at 11:03 AM, Doug Blank doug.bl...@gmail.com wrote: I need a solution for general installs. Perhaps a stand-alone Mono 2.10 install will work, if I can't build IronPython 2.7 on Mono 2.10, and then run with Mono 2.6.7... I think that the http://apebox.org/wordpress/linux/370/ link will end up being the solution. I just looked at it. It is written by Jo Shields (directhex), who is a member of the Debian mono team, IIUC. I read that (and the comments) and it is very useful. It seems that this is a common problem for many of us using Mono cross-platform, as today on another mailing list a note was sent about the same ideas: http://chrismarinos.com/f-on-ubuntu-linux-with-mono-and-monodevelop/ This version has a script for moving between mono versions, and the first link has a method for falling back to the standard, I think. Among other useful things, he says: This guide does NOT take startup scripts into account – it’s your problem to ensure you’re using the correct “mono” command to run your copy of MonoDevelop or Tomboy or whatever. The good news is: we may have an answer for that. I have in my possession a pre-release copy of an as-yet unnumbered PEP by Mark Hammond. Mark is going to propose a python launcher program for Windows, so that it will obey a shebang command to launch one of multiple versions of python. Cool! -Doug I proposed that IronPython launching ability should be included in it. The reference code he supplies is in Python, and quite simple. It would not be hard to make an Ubuntu version of a similar program, to check for and launch the appropriate version of mono and IPy. -- Vernon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] C# replacement wrapper for ipy.exe
I'm using the following C# code as a replacement for ipy.exe
myscript.py. One reason for doing this is that this can be run in the
background on Unix/Mac OSX under Mono, whereas ipy.exe can not. I
don't know if there are other reasons, or if there are speed
differences.
However, my FullFrames isn't working under IronPython 2.6 beta 2. Some
questions:
1) Is this a good replacement for ipy.exe? Anything that I should do
different or add? Any other -X flags I should consider?
2) Does FullFrames work under IronPython 2.6 beta 2 under Mono? If so,
is there something I am doing wrong?
Thanks for any ideas,
-Doug
using System;
using IronPython.Hosting;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
using System.Diagnostics;
public class MyProject {
static void Main(string[] args) {
ScriptRuntimeSetup scriptRuntimeSetup = new ScriptRuntimeSetup();
LanguageSetup language = Python.CreateLanguageSetup(null);
language.Options[FullFrames] = true;
scriptRuntimeSetup.LanguageSetups.Add(language);
ScriptRuntime runtime = new
Microsoft.Scripting.Hosting.ScriptRuntime(scriptRuntimeSetup);
ScriptScope scope = runtime.CreateScope();
ScriptEngine engine = runtime.GetEngine(python);
ScriptSource source = engine.CreateScriptSourceFromFile(myscript.py);
source.Compile();
try {
source.Execute(scope);
} catch (IronPython.Runtime.Exceptions.SystemExitException e) {
// exit
}
}
}
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] numpy / IronClad?
On Mon, Mar 14, 2011 at 1:25 PM, Jason McCampbell jmccampb...@enthought.com wrote: Hi Chad, Sorry for the delayed response, we were busy getting the beta release of NumPy and SciPy together. Microsoft announced the availability of NumPy and SciPy for IronPython / .NET at PyCon the end of last week. This is great news! Had no idea this was under development. You can find the install instructions here for the pre-built binaries: http://www.enthought.com/repo/.iron/ Alternately you can grab the source code from the following repositories: https://github.com/numpy/numpy-refactor https://github.com/jasonmccampbell/scipy-refactor One note we don't have documented right now is that SciPy requires the Python stack frames access, which IronPython doesn't enable by default. To run SciPy you need to use the -X:Frames argument: ipy.exe -X:Frames -c import scipy Regards, Jason As IronPython runs under many different operating systems now, it would be useful to know what the dependencies are for numpy and scipy: - is Windows a requirement? - does it work under Mono? - can IronRuby etc take advantage of these libraries? I tried to run the build the process with xbuild rather than msbuild, but it looks like System.Numerics might not be implemented in Mono? Thanks! -Doug On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman cha...@slb.com 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 -- Jason McCampbell Enthought, Inc. 512.850.6069 jmccampb...@enthought.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] Contents of Lib (packaging for RPM)
On Wed, Feb 9, 2011 at 3:41 PM, Andrew Jorgensen and...@jorgensenfamily.us wrote: Hello Folks, First let me thank you for making IronPython easy to compile on Mono. I'm the release manager for the Mono Project at Novell and I'm currently working on packaging IronPython and IronRuby for openSUSE (also to be included in the Mono Mac framework package). Where I've run into trouble is the stdlibs for both. I can see that the -Bin.zip contains a Lib directory with various standard libraries in it but I don't see how I can reliably and repeatably get that exact content into my RPM packages (short of including the -Bin.zip in the build). Is there a script of some sort that takes the appropriate files from the correct source and puts them where I need them (the script used to build the -Bin.zip perhaps?) +1 Happy Happy Joy Joy I was wondering if there is any effort to document (or publish) this build process on Linux so that other distributions can also build these packages for distributation? Everyone working together... sometimes it is hard to believe that we made it to this point :) Thanks to all! -Doug Thanks! Andrew Jorgensen ___ 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] Stopping, Closing, and Unloading of running IronPython code?
If you have embedded IronPython engines (and perhaps a few other DLR languages) running in a thread, what is the recommended method of stopping the running programs, and calling the objects' delete methods? For example, say you have a serial port open in an IronPython program running in a thread, and you want to stop the thread, and close the port? Is there something general that would take care of all closing, just like it would if you killed a process? Thanks for any suggestions, -Doug ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] fepy's expat.py with xmpp?
FYI, I ended up avoiding the whole issue by replacing both python-xmpp and pyexpat with a stand-alone open source XMPP library, agsXMPP. It works quite nicely, especially with the xmppd.py server, on all platforms. -Doug On Sat, Jan 29, 2011 at 5:48 PM, Douglas Blank dbl...@brynmawr.edu wrote: Anyone have any luck using fepy's pyexpat.py managed code replacement with xmpp.py on IronPython? I'm having some trouble getting the xmpp client to talk to the xmppd server, even though the CPython version works fine. About the only difference, I think, is pyexpat.py. In fepy's pyexpat, I don't understand how: def Parse(self, data, isfinal=False): self._data.append(data) if isfinal: data = .join(self._data) self._data = None self._parse(data) will do any parsing until later, but I'm pretty sure that the CPython version starts parsing right away. Am I missing something obvious? Any pointers appreciated! -Doug ___ 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] ANN: Pyjama, DLR-based IDE and shell
Dear IronPython list, Announcing the Pyjama Project, version 0.2.5. Pyjama is an IDE and shell similar to IDLE, except that it is designed for multiple languages. It can support any DLR-based language (given a small Python wrapper), and other languages as well. It comes with IronPython, IronRuby, and Sympl (as a demonstration), a not-yet-too-serious version of Scheme, and the beginnings of a drag-and-drop language, called Dinah. * Pyjama is written in IronPython * The GUI is implemented in Gtk# * It runs (via Mono) on all platforms (might run under .NET, with Gtk#---haven't tried yet) * Uses Mono.TextEditor for color syntax highlighting, etc. * Switch between languages with a keystroke (control+1 is Python, control+2 is Ruby, etc) * Designed for introductory CS courses, but allow use for power scripting users * Planned extensions for pedagogical uses (lectures, chat, interactive quizzes, etc) * integrated cross-language modules (graphics, neural networks, robotics, etc) written in C# * Pyjama Scheme is a fully proper tail-call optimized Scheme, written in Scheme and translated to C# * Cross-language support: Python can call Scheme's recursive functions, without stack; Scheme can call and access DLR functions and environment We are looking for testers to try Pyjama out, and give ideas and feedback. What would you put into a Scripting Environment, if you could do anything? Let us know! For more information, please see: http://pyjamaproject.org/ -Doug The Pyjama Project has been partially funded by Microsoft Research and the National Science Foundation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Referenced Assemblies with DLR languages
On Tue, Jan 11, 2011 at 8:13 AM, Doug Blank doug.bl...@gmail.com wrote: Two questions about referenced assemblies (which are really perhaps DLR questions): 1) I'd like to be able to use different names than are used in a DLL. For example, say I have a Library.dll, and it has a class ReallyBadName. Is there an easy way that I can rename or alias ReallyBadName after I add a reference to Library? I'd like this to work for all of my DLR languages, so I'd like to do it right after I add the reference, rather than, say, doing it in Python with import ReallyBadName as GoodName---but that is the effect I want. Ok, maybe if I ask this a slightly different way: when IronPython says import ReallyBadName where does that name need to match in order to import? I presume that I could change it somewhere in clr.References, and could import the objects via another name. Would that work? I'm trying to make generic DLLs that could be loaded directly from the DLR languages, and would be appropriate for the IP users. 2) Is there a way that I could have a Library.dll bring in other assemblies so that they would be available to DLR languages? Of course, one could load an assembly in an assembly that you clr.AddReference, but that wouldn't make it available to all of the DLR languages right? It seems that one would need a callback where the clr was passed into the assembly which was clr.AddReference-ed, so that it could add references too. Could I overload the clr importer to do that? Or is there a better way? Likewise, I'd like so that when I import Library (where Library is a DLL), it will include other DLLs to be available for DLR language access. -Doug Thanks for any pointers, -Doug ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Referenced Assemblies with DLR languages
Two questions about referenced assemblies (which are really perhaps DLR questions): 1) I'd like to be able to use different names than are used in a DLL. For example, say I have a Library.dll, and it has a class ReallyBadName. Is there an easy way that I can rename or alias ReallyBadName after I add a reference to Library? I'd like this to work for all of my DLR languages, so I'd like to do it right after I add the reference, rather than, say, doing it in Python with import ReallyBadName as GoodName---but that is the effect I want. 2) Is there a way that I could have a Library.dll bring in other assemblies so that they would be available to DLR languages? Of course, one could load an assembly in an assembly that you clr.AddReference, but that wouldn't make it available to all of the DLR languages right? It seems that one would need a callback where the clr was passed into the assembly which was clr.AddReference-ed, so that it could add references too. Could I overload the clr importer to do that? Or is there a better way? Thanks for any pointers, -Doug ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] What is a good way to determine OS platform with IronPython?
On Mon, Jan 10, 2011 at 3:37 PM, Douglas Blank dbl...@brynmawr.edu wrote: Now that IronPython runs on other operating systems, what is the recommended way to determine the os when running IP? `os.name` is probably what you want. There was some discussion on python-dev about a module (or extension to sys?) that would have a lot more information, but I can't remember what it was going to be called. Thanks. FYI, under Mono: IP on mac: os.name == 'posix' IP on linux: os.name == 'posix' IP on windows 7: os.name == 'nt' I'll have to figure out a different way to distinguish between mac and linux. Even sys.getwindowsversion() gives a platform of 4 for Mac and Linux under Mono. -Doug - 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
[IronPython] IronPython-2.0.1-Bin.zip contains 2.0.0?
Unless my system is not unzipping the right files, it looks like IronPython-2.0.1-Bin.zip on page: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481 actually has the 2.0.0 binaries: $ cd IronPython-2.0.1 $ ipy.exe -X:ColorfulConsole IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type help, copyright, credits or license for more information. Does anyone else see this? -Doug -- View this message in context: http://www.nabble.com/IronPython-2.0.1-Bin.zip-contains-2.0.0--tp22136075p22136075.html Sent from the IronPython mailing list archive at Nabble.com. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.0 RC 2 on Mono
Now that IronPython2 is out, wondering about IronPython on Mono... Seo Sanghyeon-3 wrote: Currently you need Mono SVN (both to run and to compile). Using SVN r120972 below. Any idea what version of Mono that is? Does IP2 build with Mono 2.2? It would be great to put out a IPCE r8 for IP2. Also, what would be the matching versions of IronRuby that would work with IP on Mono? I see that DevHawk has a DLR nightly build that comes with Ruby and Python: http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr but the early builds seem to be empty (I've sent Harry a note about that). The latest versions of those builds don't quite work with Mono 2.0, but perhaps Mono 2.2? Thanks for any assistance! -Doug Seo Sanghyeon-3 wrote: The binary runs fine. IronPython includes its own copy of ExtensionAttribute, but this doesn't seem to work with Mono C# compiler: that is, extension methods don't get recognized as extension methods. This causes trouble where MetaObject is defined in Microsoft.Scripting.Core.dll, and its extensions are defined in MetaObjectExtensions in Microsoft.Scripting.dll. My hack below copies MetaObjectExtensions and its dependencies to Microsoft.Scripting.Core and patch it to be a partial class instead of a static class housing extension methods. Any better idea? Also there are some unused files in the source distribution. Below are steps I used to compile the source on Mono. Download source from http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=19841 $ unzip IronPython-2.0-Src.zip $ cd IronPython-2.0 Some hacks... $ svn co -r 597 https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest build This deletes unused files and does copying mentioned above $ sh build/pre.sh Copies NAnt build file: it uses noconfig to avoid pulling System.Core.dll $ cp build/IronPython.build Src Patches $ patch -p1 build/patch-exthack $ patch -p1 build/patch-console Build $ cd Src $ nant -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- View this message in context: http://www.nabble.com/IronPython-2.0-RC-2-on-Mono-tp20889619p22120412.html Sent from the IronPython mailing list archive at Nabble.com. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
