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

[Vernon Cole]

Michael;
 IIRC you are at pycon. (I am at the wrong end of America and Mark is at the
wrong end of Earth. I couldn't make it.)
 Can you create/find a bof session to hash out a "standard" shebang?  It
should be something good enough that 2to3 could have a fixer for it.
--
[ reminder for the day:
Now is better than never.]

Mark:
  Were you thinking part of the pywin32 distribution, or CPython itself?
Either way we should have a compatible/identical tool installed with
IronPython. The thing should be Frankensteinian enough that I can have it
"cling" to my favorite distribution even when I install several others
beside it. (Perhaps an environment variable or .python file?)
--

Both/Group:
  What about Jython?  I have been using Jython 2.5 lately (not my fault -- a
college class is making me learn Java after avoiding it for 20+ years -- but
I installed the Jython support in NetBeans, too) and discover that they are
having similar problems with how to crank up a Jython script from the
command line.  The "java -jar ..." string is nasty. This starter program
could be a triple solution. Too much?
--
Vernon

P.S. -- and when I double-click on a file named "setup.py" automatically add
"install" to the generated command line.

 Tue, Mar 15, 2011 at 8:28 AM, Michael Foord wrote:

>  On 15/03/2011 07:18, Vernon Cole wrote:
>
> #!/usr/bin/ipy3
>
> A shebang on the first line is the usual way of specifying which scripting
> engine to use on a posix system. If introspection were to be used to select
> between python versions, that would be the most obvious way to do it.
>
> Windows (tm) prefers to use filename extensions, which is why .pyw is used
> to specify a GUI program. The command shell does not open the file to see
> what's inside AFAIK.
>
> It was suggested in the past  that .ipy might be used to specify IronPython
> programs. If that idea were carried to its logical end, one would use .ipy3w
> to specify an IronPython 3.x GUI script. That is a bit frightening.
>
> What about the idea of a semi-standard python dispatch program which lives
> on the search path, introspects the script, and calls the appropriate
> engine? Perhaps it could even manage to capture tracebacks sent to stderr
> when a script dies?
>
>
> There has been a long discussion recently on Python-dev [1] suggesting the
> creation of exactly such a launcher program for Python on Windows. Mark
> Hammond (copied) said he would implement it. Including IronPython support is
> a fine idea.
>
> All the best,
>
> Michael
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] ArenaNet's Use of IronPython

[Daniel Jennings]

The biggest problem we had with IronPython originally was probably the fact 
that I was the only developer on the (very small) tools team that was familiar 
with Python beyond the fact that it uses whitespace for control flow :) 

Other than that, though, the biggest things we ran into:

1. We noticed some odd discrepancies in our programs' runtime when running 
inside of the debugger versus out of the debugger. Specifically, we have a 
single line of IronPython that calls a single line of C# code that calls a 
single P/Invoke into our native code. This native code loads the content data 
for the game. When we launch the IronPython process from VS2010 with the 
debugger, then it takes upwards of 10 times as long to execute the native code. 
When we launch it with Ctrl+F5, then it operates at normal speed. I'm not sure 
what could be causing this, since the speed issues are happening in the native 
code, but I do know that launching our C# application that calls the same 
P/Invoke into the same native code (same build, same file, etc.) then there's 
no discrepancy between launching it inside of our outside of the debugger.

2. Debugging the IronPython code was difficult. If it was at the top-level of 
the file, then we couldn't inspect variables, step into some lines, etc. If we 
made a function at the top level and then called into it immediately, then we'd 
have the debugging utilities fully available. Don't know what's up with that.

3. There was a weird bug that I could reproduce with smaller code, that I can 
only attribute to IronPython. We had two larger functions that didn't depend on 
each other or mutate any shared state, etc.. Each of the functions fires off 
exceptions down in the stack and catches the exceptions. BUT, when I called one 
of those functions before the other one, it seemed like it broke the exception 
catching functionality. What I don't get is how this would be possible even if 
I were trying to break it in the same way. I would throw an IronPython defined 
exception directly inside of a try catch block that catches any CLR exception, 
or any exception, or anything, and it wouldn't catch the exception. The 
exception would bubble right on through and treat it as unhandled. At one point 
I literally had the following code, and it would still not get caught:

try:
raise Exception()
except:
print "Test"

Test wouldn't get printed, the Exception would take down the program the normal 
way. I spent a whole day looking into this, and couldn't figure out what was 
going on, so I gave up and left the two functions in the order that they were 
in when it was working, and it kept working.

4. The TryInvokeMember/TryGetMember weirdness for methods 
(http://lists.ironpython.com/pipermail/users-ironpython.com/2010-June/013104.html)
 is more weird than it lets on. I don't remember the details, but it was 
something like if the method was called with no parameters then TryGetMember 
was called first, otherwise it would call directly into TryInvokeMember. This 
meant that most of our code worked fine (we didn't cover the TryGetMember case 
at all) until we tried to write a function that didn't take any arguments and 
call it from IronPython; it didn't work and for apparently no reason (until we 
discovered that it made sense that it would call TryGetMember first).

5. I understand why the RuntimeBinderException occurs, but it's a really big 
annoyance to try to develop an application that calls over into IronPython code 
through DynamicObjects repeatedly. I wish we could decorate a class in such a 
way that it would just assume that all calls need to be reflected/whatever, so 
that it wouldn't fire hundreds of RuntimeBinderExceptions at the startup of our 
application (we were doing scripting from C# using the 'dynamic' keyword here.) 
We would always have to remember to turn off first-chance exceptions for that 
one, etc., in our otherwise first-chance exception free development environment.


These are the only things that came to mind when thinking of what we ran into 
when using IronPython; we've been developing with it for probably 6 months now 
(we've always used 2.7A1) and now ~40 game developers use our tool full-time to 
get the game built. :) As the article mentioned, we have some designers writing 
Python scripts to generate content, mutate existing content, link it together, 
etc., and it's a pretty awesome time-saver.


On a side note, it seems like IronPython could be enhanced to provide a better 
Python learning experience for new programmers. For example, it would probably 
be pretty easy to detect that you have used a function as a statement, like by 
Console.WriteLine on its own line without parentheses, and offer optional 
warning levels to help detect cases like this. :)




Daniel Jennings



-Original Message-
From: Jeff Hardy [mailto:jdha...@gmail.com] 
Sent: Monday, March 14, 2011 6:22 PM
To: Discussion of IronPython
Cc: Daniel Jennings
Subject: Re: [IronP

[IronPython] Issue with ctypes arrays of c_ubyte

[David Welden]

I have a ctypes module that is failing under Iron Python. The module is
hosted at http://essbasepy.googlecode.com if anyone wants to view the
source.

I have a union defined as:

class output_buffer(Union):
_fields_ = [('pdVal', c_double * MAX_REC),
('pbVal', c_ubyte * MAX_REC),
('pszVal', col_t * MAX_REC)]

When attempting to use the pbVal field as follows:

elif pDescr.IntTyp == MAXL_DTINT_BOOL:
pInBuff = pBuffer.pbVal
Type = MAXL_DTEXT_UCHAR
Size = 0
...
sts = maxl.MaxLColumnDefine(sid, c_ulong(index + 1), pInBuff,
c_ushort(Size), c_ulong(Type), c_ushort(MAX_REC), None, None)

the called c module fails with the following exception:

clsException in System.Collections.ListDictionaryInternal
e   {*expected c_char_Array_1025_Array_1, got c_ubyte_Array_1*} object
{IronPython.Runtime.Exceptions.PythonExceptions.BaseException}
Data{System.Collections.ListDictionaryInternal} 
System.Collections.IDictionary
{System.Collections.ListDictionaryInternal}
Message "expected c_char_Array_1025_Array_1, got c_ubyte_Array_1"   string
Source  "IronPython.Modules"string
StackTrace  "   at IronPython.Modules.ModuleOps.CheckCDataType(Object
o, Object type)\r\n   at InteropInvoker(IntPtr , Object , Object ,
Object , Object , Object , Object , Object , Object , Object[] )\r\n
at CallSite.Target(Closure , CallSite , Object , Object , Object ,
Object , Object , Object , Object , Object , Object )\r\n   at
Microsoft.Scripting.Interpreter.DynamicInstruction`10.Run(InterpretedFrame
frame)\r\n   at
Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
frame)\r\n   at
Microsoft.Scripting.Interpreter.LightLambda.Run11[T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,TRet](T0
arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7,
T8 arg8, T9 arg9, T10 arg10)\r\n   at
Essbase$2._MaxlOutputNextRecord$70(PythonFunction $function, Object
self, Object sid, Object ssnInit, Object numFlds) in C:\\Program
Files\\IronPython 2.7\\lib\\site-packages\\Essbase.py:line 376" string
TargetSite  {CData CheckCDataType(System.Object,
System.Object)} System.Reflection.MethodBase
{System.Reflection.RuntimeMethodInfo}

I am a little out of my depth here, so hoping someone understands
ctypes in general and the Iron Python implementation in particular.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Tomas Matousek]

The assemblies are strongly named so I don't think that the name change would 
be necessary.

Tomas

-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Tuesday, March 15, 2011 11:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2.7.1 & 3.x Development

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

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

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

Would this be useful for anyone else as well?

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




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

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

[Jeff Hardy]

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

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

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

Would this be useful for anyone else as well?

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

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

[Markus Schaber]

Hi, Vernon,

Von: Vernon Cole
> #!/usr/bin/ipy3
> A shebang on the first line is the usual way of specifying which
scripting engine to use on a posix system.

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

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 

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

Re: [IronPython] no module named re

[Slide]

Yes, but I just found that it was not being copied to the bin
directory during build for some reason.

Sorry for the noise.

slide

On Tue, Mar 15, 2011 at 9:29 AM, Jimmy Schementi  wrote:
> Is IronPython.Modules.dll referenced by the host app?
> ~Jimmy
>
>
> On Tue, Mar 15, 2011 at 12:22 PM, Slide  wrote:
>>
>> I am embedding IronPython in my app to allow some script capabilities.
>> I have the following code:
>>
>> _content = content.Trim();
>>
>>            string script = string.Format(@"
>> import re
>>
>> def interp(string, variables):
>>    globals = globals()
>>    for item in re.findall(r'\$\(([^{{]*)\)', string):
>>        string = string.replace('$(%s)' % item,
>>                            str(eval(item, globals, variables)))
>>    return string
>>
>> {0}
>> ", _content);
>>
>>            try
>>            {
>>                _engine = Python.CreateEngine();
>>                List searchPaths = new
>> List(_engine.GetSearchPaths());
>>                searchPaths.Add(
>>
>> Path.GetDirectoryName(Assembly.GetEntryAssembly().Location));
>>
>>                _engine.SetSearchPaths(searchPaths);
>>                ScriptSource source =
>>                    _engine.CreateScriptSourceFromString(script);
>>
>>                _script = source.Compile();
>>            }
>>            catch(SyntaxErrorException ex)
>>            {
>>                ExceptionOperations eo =
>>                    _engine.GetService();
>>                throw new ScriptedStringParseException(
>>                    eo.FormatException(ex), -1);
>>            }
>>
>> Then later I call:
>>
>> _script.DefaultScope.SetVariable("context",
>>                GenerateParameters(context));
>>            return _script.Execute();
>>
>> The problem I am running into is that _script.Execute is that I am
>> getting an import exception on the "import re"
>>
>> re is a builtin module, so I am not sure why that is happening, does
>> the IronPython.Modules.dll need to be in the DLLs directory? I don't
>> remember having this issue previously.
>>
>> --
>> slide-o-blog
>> http://slide-o-blog.blogspot.com/
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>



-- 
slide-o-blog
http://slide-o-blog.blogspot.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] no module named re

[Jimmy Schementi]

Is IronPython.Modules.dll referenced by the host app?

~Jimmy


On Tue, Mar 15, 2011 at 12:22 PM, Slide  wrote:

> I am embedding IronPython in my app to allow some script capabilities.
> I have the following code:
>
> _content = content.Trim();
>
>string script = string.Format(@"
> import re
>
> def interp(string, variables):
>globals = globals()
>for item in re.findall(r'\$\(([^{{]*)\)', string):
>string = string.replace('$(%s)' % item,
>str(eval(item, globals, variables)))
>return string
>
> {0}
> ", _content);
>
>try
>{
>_engine = Python.CreateEngine();
>List searchPaths = new
> List(_engine.GetSearchPaths());
>searchPaths.Add(
>
> Path.GetDirectoryName(Assembly.GetEntryAssembly().Location));
>
>_engine.SetSearchPaths(searchPaths);
>ScriptSource source =
>_engine.CreateScriptSourceFromString(script);
>
>_script = source.Compile();
>}
>catch(SyntaxErrorException ex)
>{
>ExceptionOperations eo =
>_engine.GetService();
>throw new ScriptedStringParseException(
>eo.FormatException(ex), -1);
>}
>
> Then later I call:
>
> _script.DefaultScope.SetVariable("context",
>GenerateParameters(context));
>return _script.Execute();
>
> The problem I am running into is that _script.Execute is that I am
> getting an import exception on the "import re"
>
> re is a builtin module, so I am not sure why that is happening, does
> the IronPython.Modules.dll need to be in the DLLs directory? I don't
> remember having this issue previously.
>
> --
> slide-o-blog
> http://slide-o-blog.blogspot.com/
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] no module named re

[Slide]

I am embedding IronPython in my app to allow some script capabilities.
I have the following code:

_content = content.Trim();

string script = string.Format(@"
import re

def interp(string, variables):
globals = globals()
for item in re.findall(r'\$\(([^{{]*)\)', string):
string = string.replace('$(%s)' % item,
str(eval(item, globals, variables)))
return string

{0}
", _content);

try
{
_engine = Python.CreateEngine();
List searchPaths = new
List(_engine.GetSearchPaths());
searchPaths.Add(

Path.GetDirectoryName(Assembly.GetEntryAssembly().Location));

_engine.SetSearchPaths(searchPaths);
ScriptSource source =
_engine.CreateScriptSourceFromString(script);

_script = source.Compile();
}
catch(SyntaxErrorException ex)
{
ExceptionOperations eo =
_engine.GetService();
throw new ScriptedStringParseException(
eo.FormatException(ex), -1);
}

Then later I call:

_script.DefaultScope.SetVariable("context",
GenerateParameters(context));
return _script.Execute();

The problem I am running into is that _script.Execute is that I am
getting an import exception on the "import re"

re is a builtin module, so I am not sure why that is happening, does
the IronPython.Modules.dll need to be in the DLLs directory? I don't
remember having this issue previously.

-- 
slide-o-blog
http://slide-o-blog.blogspot.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

[Jason McCampbell]

On Tue, Mar 15, 2011 at 9:19 AM, Jones, Larry wrote:

> Great work on SciPy and NumPy!
>
>
>
> Any plans for IPython?
>

Not that I'm aware of, but a lot depends on how the IronPython community
develops and how it's used.  Microsoft has released their Python Tools for
Visual Studio package that has some similar functionality which looks quite
interesting, though I haven't had a chance to really work it yet.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

[Jason McCampbell]

On Tue, Mar 15, 2011 at 3:00 AM, Federico Vaggi  wrote:

>  Hey Jason, thanks for all the work on this.  I use the enthought python
> distribution, and it appears that the ironpkg package has some conflict with
> installer present in python - here is what happens if you run ironpkg after
> installing it:
>
> C:\TEMP>ipy ironpkg-1.0.0.py --install
> Bootstrapping:
> c:\users\fedev\appdata\local\temp\tmpzaqqhk\ironpkg-1.0.0-1.egg
>118 KB
> [.]
>
> C:\TEMP>ironpkg scipy
> Traceback (most recent call last):
>   File "C:\Program Files (x86)\IronPython 2.7\ironpkg-script.py", line 8,
> in  dule>
>   File "C:\Python27\Lib\site-packages\enstaller\main.py", line 19, in
> 
>   File "C:\Python27\Lib\site-packages\enstaller\config.py", line 11, in
> 
>
>   File "C:\Python27\Lib\site-packages\enstaller\utils.py", line 1, in
> 
> ImportError: No module named bz2
>
> My guess is that since python site-lib and ironpython site-lib are on the
> path, the installer tries to look through the python lib first?
>
> Either way, should be easy to fix, I'll just grab the version from git and
> play around with it.
>

Hi Federico, the packager was just something quick we put together since
there wasn't an existing one for IronPython and we needed a way to manage
packages.  I haven't seen an install of IronPython that has both the CPython
and IronPython site-packages directories in the same path and I'm not
surprised the packager doesn't handle it.

Does putting both site-packages directories in the same path work in
general? It seems like it would lead to issues with getting the wrong
versions of packages, but perhaps not.

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

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

[Michael Foord]

On 15/03/2011 07:18, Vernon Cole wrote:


#!/usr/bin/ipy3

A shebang on the first line is the usual way of specifying which 
scripting engine to use on a posix system. If introspection were to be 
used to select between python versions, that would be the most obvious 
way to do it.


Windows (tm) prefers to use filename extensions, which is why .pyw is 
used to specify a GUI program. The command shell does not open the 
file to see what's inside AFAIK.


It was suggested in the past  that .ipy might be used to specify 
IronPython programs. If that idea were carried to its logical end, one 
would use .ipy3w to specify an IronPython 3.x GUI script. That is a 
bit frightening.


What about the idea of a semi-standard python dispatch program which 
lives on the search path, introspects the script, and calls the 
appropriate engine? Perhaps it could even manage to capture tracebacks 
sent to stderr when a script dies?




There has been a long discussion recently on Python-dev [1] suggesting 
the creation of exactly such a launcher program for Python on Windows. 
Mark Hammond (copied) said he would implement it. Including IronPython 
support is a fine idea.


All the best,

Michael

[1] http://mail.python.org/pipermail/python-dev/2011-March/108872.html


--
Vernon Cole
(sent from my 'droid phone)

On Mar 15, 2011 3:20 AM, "Markus Schaber" > wrote:

Hi, Jeff,

Von: Jeff Hardy


> With the 2.7 out the door, it's time to start thinking about 3.x. I've
> created a ipy-2.7-maint ...

Your plans sound good for us.

But we're just releasing a product hosting IronPython 2.6.2, as we're
still bound to .NET 2.0 for some months, but our plans to upgrade to
.NET 4.0 are on the way. So we are interested in smooth migration paths
for our customers.

Will it be possible to integrate / host both python 2.x (2.7.x) and 3.x
in the same application?

And is there some mechanism to auto-recognize whether a Script is python
2.x or 3.x syntax? Maybe some "from __future__ import Python3" or
something?

If there's work needed in that area, maybe I can convince my seniors
that we contribute.

(I used to work a lot with Python and contribute to free projects in
some of my former working places...)





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

___
Users mailing list
Users@lists.ironpython.com 
http:/...



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



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

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

Re: [IronPython] numpy / IronClad?

[Jones, Larry]

Great work on SciPy and NumPy!

 

Any plans for IPython?

 

---

Larry Jones
||| Senior Level Development Engineer
Aspen Technology, Inc. ||| +1 281-504-3324 ||| fax: 281-584-1062 ||| 
www.aspentech.com   

 

   

 

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jason McCampbell
Sent: Monday, March 14, 2011 12:25 PM
To: Discussion of IronPython
Cc: Chad Brockman
Subject: Re: [IronPython] numpy / IronClad?

 

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.

 

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

 

On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman  wrote:

Anyone know if the effort to port numpy to IronPython is still alive? Enthought 
/ MS announced it last year? http://www.enthought.com/media/SciPyNumPyDotNet.pdf

 

Anyone know if IronClad is still being developed?

 

Thanks, Chad


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




-- 
Jason McCampbell

Enthought, Inc.

512.850.6069

jmccampb...@enthought.com

 




This e-mail and any attachments are intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of
this e-mail, you are hereby notified any dissemination,
distribution or copying of this email, and any attachments thereto,
is strictly prohibited. If you receive this email in error please
immediately notify the sender and permanently delete the original
copy and any copy of any e-mail, and any printout thereof.<>___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Vernon Cole]

#!/usr/bin/ipy3

A shebang on the first line is the usual way of specifying which scripting
engine to use on a posix system. If introspection were to be used to select
between python versions, that would be the most obvious way to do it.

Windows (tm) prefers to use filename extensions, which is why .pyw is used
to specify a GUI program. The command shell does not open the file to see
what's inside AFAIK.

It was suggested in the past  that .ipy might be used to specify IronPython
programs. If that idea were carried to its logical end, one would use .ipy3w
to specify an IronPython 3.x GUI script. That is a bit frightening.

What about the idea of a semi-standard python dispatch program which lives
on the search path, introspects the script, and calls the appropriate
engine? Perhaps it could even manage to capture tracebacks sent to stderr
when a script dies?
--
Vernon Cole
(sent from my 'droid phone)

On Mar 15, 2011 3:20 AM, "Markus Schaber"  wrote:
Hi, Jeff,

Von: Jeff Hardy


> With the 2.7 out the door, it's time to start thinking about 3.x. I've
> created a ipy-2.7-maint ...
Your plans sound good for us.

But we're just releasing a product hosting IronPython 2.6.2, as we're
still bound to .NET 2.0 for some months, but our plans to upgrade to
.NET 4.0 are on the way. So we are interested in smooth migration paths
for our customers.

Will it be possible to integrate / host both python 2.x (2.7.x) and 3.x
in the same application?

And is there some mechanism to auto-recognize whether a Script is python
2.x or 3.x syntax? Maybe some "from __future__ import Python3" or
something?

If there's work needed in that area, maybe I can convince my seniors
that we contribute.

(I used to work a lot with Python and contribute to free projects in
some of my former working places...)

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

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

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

[Markus Schaber]

Hi, Jeff,

Von: Jeff Hardy

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

Your plans sound good for us. 

But we're just releasing a product hosting IronPython 2.6.2, as we're
still bound to .NET 2.0 for some months, but our plans to upgrade to
.NET 4.0 are on the way. So we are interested in smooth migration paths
for our customers.

Will it be possible to integrate / host both python 2.x (2.7.x) and 3.x
in the same application?

And is there some mechanism to auto-recognize whether a Script is python
2.x or 3.x syntax? Maybe some "from __future__ import Python3" or
something?

If there's work needed in that area, maybe I can convince my seniors
that we contribute.

(I used to work a lot with Python and contribute to free projects in
some of my former working places...)

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 
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

[Federico Vaggi]

Hey Jason, thanks for all the work on this.  I use the enthought python 
distribution, and it appears that the ironpkg package has some conflict 
with installer present in python - here is what happens if you run 
ironpkg after installing it:


C:\TEMP>ipy ironpkg-1.0.0.py --install
Bootstrapping: 
c:\users\fedev\appdata\local\temp\tmpzaqqhk\ironpkg-1.0.0-1.egg
   118 KB 
[.]


C:\TEMP>ironpkg scipy
Traceback (most recent call last):
  File "C:\Program Files (x86)\IronPython 2.7\ironpkg-script.py", line 
8, in 
dule>
  File "C:\Python27\Lib\site-packages\enstaller\main.py", line 19, in 

  File "C:\Python27\Lib\site-packages\enstaller\config.py", line 11, in 



  File "C:\Python27\Lib\site-packages\enstaller\utils.py", line 1, in 


ImportError: No module named bz2

My guess is that since python site-lib and ironpython site-lib are on 
the path, the installer tries to look through the python lib first?


Either way, should be easy to fix, I'll just grab the version from git 
and play around with it.


Federico

On 14/03/2011 18:25, Jason McCampbell 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.


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


On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman > wrote:


Anyone know if the effort to port numpy to IronPython is still
alive? Enthought / MS announced it last year?
http://www.enthought.com/media/SciPyNumPyDotNet.pdf

Anyone know if IronClad is still being developed?

Thanks, Chad


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




--
*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