From chinyoka.consultant at gmail.com Sun Aug 1 02:15:57 2010 From: chinyoka.consultant at gmail.com (Ishe Chinyoka) Date: Sun, 1 Aug 2010 02:15:57 +0200 Subject: [IronPython] Announcing adodbapi version 2.4.0 -- with COLUMN NAMEdata access References: Message-ID: <4102A3B5A9B94B749814FF75EC9E8880@chinyoka847a4b> Thanks for this database tool, but where on earth can one download this? I had been looking for such a tool to connect my apps to databases. Thanks. Ishe We all have the right to be wrong in our opinions but not in our facts. ----- Original Message ----- From: Vernon Cole To: Discussion of IronPython Sent: Saturday, July 31, 2010 9:42 AM Subject: [IronPython] Announcing adodbapi version 2.4.0 -- with COLUMN NAMEdata access Announcing a new version of adodbapi... [ for those who may not know... [ adodbapi is a pure Python package which fully implements the PEP-249 db-api [ using Microsoft ADO/db. [ It runs on CPython versions 2.3 and later, IronPython 2.6 and later, [ or Python 3.0 and later. I have often been frustrated by the need to count '?' marks for input parameters and remembering column numbers to get my SQL output. This release fixes that by allowing the use of 'named' parameters as an option, and by returning 'SQLrow' objects which allow the use of column names. This version includes a distutils setup.py file, so installation is easy. Just 1) unzip 2) "cd" to the directory you just unzipped. 2) Execute the command: python setup.py install using the python distribution of your choice. It even runs 2to3 automatically if you run it using a 3.n Python. (Why didn't I do this years ago?) NOTE: on Vista (and 7?) you must run setup.py using the administrator account to install on IronPython, because setup.py does not elevate privileges for the source installer. (Distutils can create a stand-alone binary installer which does elevate privileges, but that feature is not yet supported by IronPython because it has no zip library.) ALSO NOTE: I have _used_ this package with IronPython 2.7.A1, but not _tested_ it, because 2.7's unittest package is broken. Here's what's new............................ * adodbapi version 2.4.0 -- in this version, "fetchall()" and "fetchmany()" return an SQLrows object ...which emulates a sequence of SQLrow objects. "fetchone()" or the cursor's "next()" method return an SQLrow object. An SQLrow object emulates a tuple of data fields. An SQLrow object also appears to have an attribute for each column of data. therefore... >>> import adodbapi >>> myConnection = adodbapi.connection('someDSN') >>> cur = myConnection.cursor() >>> cur.execute("select name, rank, serialNumber from soldiers") >>> row = cur.fetchone() >>> assert row[0] == row['name'] >>> assert row[1] == row.rank >>> rows = cur.fecthall() >>> assert rows[4,'serialNumber'] == rows[4][2] * adodbapi version 2.3.0 -- this is includes major refactoring and specifically adds features for django support, including the ability for the programmer to change ado's SQL "paramstyle" at run time to select between 'qmark', 'format' and 'named' methods of passing SQL parameters. ** also, in response to user requests, adodbapi will now use client-side cursors by default. This will make rowcount and stored procedure return parameter values more readily available. ------------------------------------------------------------------------------ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Sun Aug 1 04:09:46 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Sat, 31 Jul 2010 20:09:46 -0600 Subject: [IronPython] Announcing adodbapi version 2.4.0 -- with COLUMN NAMEdata access In-Reply-To: <4102A3B5A9B94B749814FF75EC9E8880@chinyoka847a4b> References: <4102A3B5A9B94B749814FF75EC9E8880@chinyoka847a4b> Message-ID: Forgot the link, didn't I? Sorry! http://sourceforge.net/projects/adodbapi Vernon On Sat, Jul 31, 2010 at 6:15 PM, Ishe Chinyoka < chinyoka.consultant at gmail.com> wrote: > Thanks for this database tool, but where on earth can one download this? > > I had been looking for such a tool to connect my apps to databases. Thanks. > > Ishe > We all have the right to be wrong in our opinions but not in our facts. > > ----- Original Message ----- > *From:* Vernon Cole > *To:* Discussion of IronPython > *Sent:* Saturday, July 31, 2010 9:42 AM > *Subject:* [IronPython] Announcing adodbapi version 2.4.0 -- with COLUMN > NAMEdata access > > Announcing a new version of adodbapi... > > [ for those who may not know... > [ adodbapi is a pure Python package which fully implements the PEP-249 > db-api > [ using Microsoft ADO/db. > [ It runs on CPython versions 2.3 and later, IronPython 2.6 and later, > [ or Python 3.0 and later. > > I have often been frustrated by the need to count '?' marks for input > parameters > and remembering column numbers to get my SQL output. > This release fixes that by allowing the use of 'named' parameters as an > option, > and by returning 'SQLrow' objects which allow the use of column names. > > This version includes a distutils setup.py file, so installation is easy. > Just > 1) unzip > 2) "cd" to the directory you just unzipped. > 2) Execute the command: > python setup.py install > using the python distribution of your choice. > It even runs 2to3 automatically if you run it using a 3.n Python. > (Why didn't I do this years ago?) > > NOTE: on Vista (and 7?) you must run setup.py using the administrator > account to install on IronPython, > because setup.py does not elevate privileges for the source installer. > (Distutils can create a stand-alone binary installer which does elevate > privileges, but that feature is not yet supported by IronPython because it > has no zip library.) > > ALSO NOTE: I have _used_ this package with IronPython 2.7.A1, but not > _tested_ it, because 2.7's unittest package is broken. > > Here's what's new............................ > > * adodbapi version 2.4.0 -- in this version, > "fetchall()" and "fetchmany()" return an SQLrows object > ...which emulates a sequence of SQLrow objects. > "fetchone()" or the cursor's "next()" method return an SQLrow object. > An SQLrow object emulates a tuple of data fields. > An SQLrow object also appears to have an attribute for each column of > data. > therefore... > >>> import adodbapi > >>> myConnection = adodbapi.connection('someDSN') > >>> cur = myConnection.cursor() > >>> cur.execute("select name, rank, serialNumber from soldiers") > >>> row = cur.fetchone() > >>> assert row[0] == row['name'] > >>> assert row[1] == row.rank > >>> rows = cur.fecthall() > >>> assert rows[4,'serialNumber'] == rows[4][2] > > * adodbapi version 2.3.0 -- this is includes major refactoring and > specifically adds features for django support, including the ability for > the > programmer to change ado's SQL "paramstyle" at run time to select > between > 'qmark', 'format' and 'named' methods of passing SQL parameters. > ** also, in response to user requests, adodbapi will now use client-side > cursors by default. This will make rowcount and stored procedure return > > parameter values more readily available. > > > ------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Sun Aug 1 10:08:38 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Sun, 01 Aug 2010 10:08:38 +0200 Subject: [IronPython] Announcing adodbapi version 2.4.0 -- with COLUMN NAME data access In-Reply-To: References: Message-ID: <4C552B86.20706@bakalari.cz> Hi all, I have developed my internal tool for accessing SQL server and FoxPro .dbf files. It is inspired by PEP 249 too but it uses System.Data.SqlClient.SqlConnection respectively System.Data.OleDb.OleDbConnection (vfpoledb.dll). It's main goal is to cover differences between SQL server and FoxPro. If anybody is interested, let me know and I will try to make it public. -- -- Luk?s( On 31.7.2010 9:42, Vernon Cole wrote: > Announcing a new version of adodbapi... > > [ for those who may not know... > [ adodbapi is a pure Python package which fully implements the PEP-249 > db-api > [ using Microsoft ADO/db. > [ It runs on CPython versions 2.3 and later, IronPython 2.6 and later, > [ or Python 3.0 and later. > > I have often been frustrated by the need to count '?' marks for input > parameters > and remembering column numbers to get my SQL output. > This release fixes that by allowing the use of 'named' parameters as > an option, > and by returning 'SQLrow' objects which allow the use of column names. > > This version includes a distutils setup.py file, so installation is easy. > Just > 1) unzip > 2) "cd" to the directory you just unzipped. > 2) Execute the command: > python setup.py install > using the python distribution of your choice. > It even runs 2to3 automatically if you run it using a 3.n Python. > (Why didn't I do this years ago?) > > NOTE: on Vista (and 7?) you must run setup.py using the administrator > account to install on IronPython, > because setup.py does not elevate privileges for the source installer. > (Distutils can create a stand-alone binary installer which does > elevate privileges, but that feature is not yet supported by > IronPython because it has no zip library.) > > ALSO NOTE: I have _used_ this package with IronPython 2.7.A1, but not > _tested_ it, because 2.7's unittest package is broken. > > Here's what's new............................ > > * adodbapi version 2.4.0 -- in this version, > "fetchall()" and "fetchmany()" return an SQLrows object > ...which emulates a sequence of SQLrow objects. > "fetchone()" or the cursor's "next()" method return an SQLrow object. > An SQLrow object emulates a tuple of data fields. > An SQLrow object also appears to have an attribute for each column > of data. > therefore... > >>> import adodbapi > >>> myConnection = adodbapi.connection('someDSN') > >>> cur = myConnection.cursor() > >>> cur.execute("select name, rank, serialNumber from soldiers") > >>> row = cur.fetchone() > >>> assert row[0] == row['name'] > >>> assert row[1] == row.rank > >>> rows = cur.fecthall() > >>> assert rows[4,'serialNumber'] == rows[4][2] > > * adodbapi version 2.3.0 -- this is includes major refactoring and > specifically adds features for django support, including the > ability for the > programmer to change ado's SQL "paramstyle" at run time to select > between > 'qmark', 'format' and 'named' methods of passing SQL parameters. > ** also, in response to user requests, adodbapi will now use client-side > cursors by default. This will make rowcount and stored procedure > return > parameter values more readily available. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Mon Aug 2 17:13:16 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Mon, 2 Aug 2010 08:13:16 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/74728. ADDED SOURCES $/IronPython/IronPython_Main/Solutions/Common.proj MODIFIED SOURCES $/IronPython/IronPython_Main/Hosts/MerlinWeb/examples/Web.config $/IronPython/IronPython_Main/Hosts/MerlinWeb/Microsoft.Scripting.AspNet/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Hosts/MerlinWeb/Microsoft.Scripting.AspNet/Microsoft.Scripting.AspNet.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Compiler/Parser.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Modules/datetime.cs $/IronPython/IronPython_Main/Languages/IronPython/Tests/hosting/editor_svcs/tokencategorizer.py $/IronPython/IronPython_Main/Languages/IronPython/Scripts/generate_ops.py $/IronPython/IronPython_Main/Hosts/Silverlight/Microsoft.Scripting.SilverLight/Microsoft.Scripting.Silverlight.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/IronPython.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Compiler/Tokenizer.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Modules/IronPython.Modules.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Modules/time.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonConsoleAny/IronPythonConsoleAny.csproj $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Chiron.csproj $/IronPython/IronPython_Main/Languages/IronPython/App.config $/IronPython/IronPython_Main/Languages/IronPython/IronPythonWindow/IronPythonWindow.csproj $/IronPython/IronPython_Main/Languages/IronPython/AssemblyVersion.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Operations/StringOps.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Metadata/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Metadata/Microsoft.Scripting.Metadata.csproj $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/system_related/time_test.py $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_syntax.py $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Debugging/Microsoft.Scripting.Debugging.csproj $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonConsole/IronPythonConsole.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/LiteralParser.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Compiler/TokenKind.Generated.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/IronPythonTest.csproj $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonWindowAny/IronPythonWindowAny.csproj $/IronPython/IronPython_Main/Config/Unsigned/App.config $/IronPython/IronPython_Main/Config/Signed/App.config $/IronPython/IronPython_Main/Solutions/Common.proj $/IronPython/IronPython_Main/Tools/IronStudio/Common.proj $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting/Hosting/ScriptEngine.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting/Hosting/CompiledCode.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Test/ClrAssembly/ClrAssembly.csproj $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting/Hosting/ScriptSource.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/VisualStudio/Project/Microsoft.VisualStudio.Project.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/RemoteScriptFactory/Properties/AssemblyInfo.cs CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1948052 Date: 7/30/2010 6:14:28 PM Updated assembly version numbers for IronPython 2.7 Beta 1 now so that I can utilize IronPython Tools 2.7 A1 (which is GACed), and test the latest and greatest IronPython concurrently: - updated IronPython assembly version number to 2.7.0.10 reflecting 2.7B1 - updated DLR assembly version number to 1.1.0.10 reflecting 1.1B1 (Shelveset: ASMVERCHANGE;REDMOND\dfugate | SNAP CheckinId: 11222) -------------------------------------------------------------------------------- Changeset Id: 1946441 Date: 7/29/2010 8:14:52 PM Improves memory usage of the parser/tokenizer and fixes a date/time parsing bug. All combined this is over a 20% reduction in parser allocations while parsing the standard library. Parser optimizations: Improve FixName performance (doesn?t really matter, but String.Format is overkill here) Reduce allocations for ParseTestListAsExpr when there?s only a single expression (which is very common) so we don?t allocate a List every time through Also simplifies the call by dropping the bool flag ? only one caller passed true, and it had already checked that there was at least one expression present. Reduce allocations in FinishAssignments ? again the common case is 1 RHS, don?t allocate a list in that case Move to using a hash set for verifying unique parameter names in a function definition. Use the arg list for CheckUniqueArgument ? this is for function calls where KW arguments are rare so iterating is cheap. Tokenizer optimizations: Don?t use a dictionary for looking up keywords ? instead we have generated code which pulls of each individual character and returns the KW if we hit it. Use a dictionary for creating only a single NameToken ? define an IEqualityComparer so we can do the lookup w/o creating a temporary string. Combined this reduces string creation into 1/6th of what it was before. These strings also all stick around w/ the AST so this is a good overall memory reduction in addition to reducing temporary allocations. Add back the IncompleteStringToken in state ? this broken parsing of triple quoted strings in IpyTools. Update string parsing so that we don?t copy the string ? we used make up to 3 new strings here ? once for normalizing multi-line endings, once for pulling the string out to unescape, and once to produce the final string. Now we always just produce the final string. Avoid boxing some integers and instead go to our int cache Also makes State class internal Fixes parsing of %H/%h which need to accept single digits. We also need to read day of week component. (Shelveset: MemoryOpts;REDMOND\dinov | SNAP CheckinId: 11218) -------------------------------------------------------------------------------- Changeset Id: 1948052 Date: 7/30/2010 6:14:28 PM Updated assembly version numbers for IronPython 2.7 Beta 1 now so that I can utilize IronPython Tools 2.7 A1 (which is GACed), and test the latest and greatest IronPython concurrently: - updated IronPython assembly version number to 2.7.0.10 reflecting 2.7B1 - updated DLR assembly version number to 1.1.0.10 reflecting 1.1B1 (Shelveset: ASMVERCHANGE;REDMOND\dfugate | SNAP CheckinId: 11222) From cory.brostowicz at gmail.com Mon Aug 2 20:41:55 2010 From: cory.brostowicz at gmail.com (Cory Brostowicz) Date: Mon, 2 Aug 2010 13:41:55 -0500 Subject: [IronPython] Exception Performance Message-ID: Hello, I noticed the performance in one of my python scripts has really bad performance, so I started profiling different sections of the script to find out where the issue is. It turns out, the exception handle seems to add the biggest chunk of time. I've fairly new to the Python language, so if there is a better way to do what I'm doing, then please let me know. Below is the code that I'm executing, followed by the output I received with the timings. Notice that when the rate is "X" or a numeric value, the script execution is much faster than when I enter the exception handler. I'm running the following version of IronPython: IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1 [CODE] from System.Diagnostics import Stopwatch t = Stopwatch() s = Stopwatch() e = Stopwatch() t.Start() s.Start() Rate = PH.GetFieldString("RATE") s.Stop() rateGet = s.Elapsed.TotalMilliseconds s.Reset(); if Rate == "X": s.Start() #Sets some values... s.Stop() rateSet = s.Elapsed.TotalMilliseconds else: try: e.Start() fRate = float(Rate) e.Stop() if fRate > 15: s.Start() #Sets some values... s.Stop(); rateSet = s.Elapsed.TotalMilliseconds else: s.Start() #Sets some values... s.Stop(); rateSet = s.Elapsed.TotalMilliseconds except ValueError: e.Stop() s.Start() #Sets some values... s.Stop(); rateSet = s.Elapsed.TotalMilliseconds t.Stop() print "Total: " + str(t.Elapsed.TotalMilliseconds) + " RateGet: " + str(rateGet) + " RateSets: " + str(rateSet) + " Exception Handle: " + str(e.Elapsed.TotalMilliseconds) + " Rate: " + str(Rate) s.Reset() t.Reset() [Output] Total: 55.402 RateGet: 0.4303 RateSets: 7.5158 Exception Handle: 37.335 Rate: B Total: 10.026 RateGet: 0.1507 RateSets: 0.38 Exception Handle: 0.1118 Rate: 30 Total: 1.1308 RateGet: 0.1442 RateSets: 0.3553 Exception Handle: 0.0838 Rate: 25 Total: 19.9077 RateGet: 0.145 RateSets: 0.3954 Exception Handle: 18.8591 Rate: A Total: 18.8859 RateGet: 0.147 RateSets: 1.427 Exception Handle: 16.8182 Rate: A Total: 18.2704 RateGet: 0.2301 RateSets: 0.6179 Exception Handle: 16.6897 Rate: A Total: 17.5447 RateGet: 0.1401 RateSets: 0.3707 Exception Handle: 16.5629 Rate: A Total: 17.43 RateGet: 0.147 RateSets: 0.3796 Exception Handle: 16.4166 Rate: B Total: 17.3939 RateGet: 0.1377 RateSets: 0.3602 Exception Handle: 16.4227 Rate: B Total: 17.3923 RateGet: 0.1418 RateSets: 0.3788 Exception Handle: 16.3627 Rate: B Total: 1.1993 RateGet: 0.1134 RateSets: 0.6827 Exception Handle: 0.0 Rate: X Total: 18.6249 RateGet: 0.1057 RateSets: 0.3808 Exception Handle: 17.6504 Rate: A Total: 17.0674 RateGet: 0.0745 RateSets: 0.3229 Exception Handle: 16.3526 Rate: L Total: 17.4021 RateGet: 0.0867 RateSets: 0.3521 Exception Handle: 16.6277 Rate: B Total: 17.4973 RateGet: 0.0741 RateSets: 0.4258 Exception Handle: 16.5078 Rate: A Total: 17.4251 RateGet: 0.0842 RateSets: 0.3391 Exception Handle: 16.652 Rate: A Total: 17.3559 RateGet: 0.0757 RateSets: 0.3253 Exception Handle: 16.6212 Rate: A Total: 17.885 RateGet: 0.0765 RateSets: 0.3277 Exception Handle: 17.1354 Rate: A Total: 17.898 RateGet: 0.0769 RateSets: 0.4226 Exception Handle: 16.8992 Rate: A Total: 17.9381 RateGet: 0.0773 RateSets: 0.3257 Exception Handle: 17.2023 Rate: A Total: 17.6204 RateGet: 0.0786 RateSets: 0.3444 Exception Handle: 16.851 Rate: B Total: 22.097 RateGet: 0.2589 RateSets: 0.4376 Exception Handle: 20.3052 Rate: B Total: 16.817 RateGet: 0.0782 RateSets: 0.3249 Exception Handle: 16.0783 Rate: A Total: 18.1557 RateGet: 0.0798 RateSets: 0.3715 Exception Handle: 17.3765 Rate: A Total: 17.3117 RateGet: 0.0765 RateSets: 0.4347 Exception Handle: 16.3117 Rate: A Total: 17.3433 RateGet: 0.0854 RateSets: 0.3415 Exception Handle: 16.5674 Rate: A Total: 17.8072 RateGet: 0.0741 RateSets: 0.3602 Exception Handle: 17.0503 Rate: A Total: 21.0285 RateGet: 1.312 RateSets: 1.9955 Exception Handle: 17.2302 Rate: A Total: 17.4693 RateGet: 0.0733 RateSets: 0.269 Exception Handle: 16.7947 Rate: A Total: 17.1699 RateGet: 0.0806 RateSets: 0.2666 Exception Handle: 16.4798 Rate: A Total: 17.2841 RateGet: 0.083 RateSets: 0.2649 Exception Handle: 16.6168 Rate: A Total: 17.5892 RateGet: 0.0773 RateSets: 0.3731 Exception Handle: 16.7914 Rate: L Total: 16.9316 RateGet: 0.0761 RateSets: 0.3233 Exception Handle: 16.0309 Rate: L Total: 17.3713 RateGet: 0.0725 RateSets: 0.254 Exception Handle: 16.7209 Rate: L Total: 17.1828 RateGet: 0.0794 RateSets: 0.2686 Exception Handle: 16.505 Rate: L Total: 17.302 RateGet: 0.0786 RateSets: 0.2556 Exception Handle: 16.6391 Rate: A Total: 17.319 RateGet: 0.0757 RateSets: 0.3314 Exception Handle: 16.413 Rate: A Total: 17.0678 RateGet: 0.0794 RateSets: 0.269 Exception Handle: 16.3802 Rate: A Total: 0.8533 RateGet: 0.0749 RateSets: 0.3889 Exception Handle: 0.0522 Rate: 30 Total: 17.6281 RateGet: 0.0725 RateSets: 0.3298 Exception Handle: 16.8968 Rate: A Total: 17.6294 RateGet: 0.0769 RateSets: 0.2556 Exception Handle: 16.9576 Rate: A Total: 18.3972 RateGet: 0.0725 RateSets: 0.2698 Exception Handle: 17.708 Rate: L Total: 17.7363 RateGet: 0.0822 RateSets: 0.3196 Exception Handle: 16.8319 Rate: L Total: 17.8036 RateGet: 0.0798 RateSets: 0.2807 Exception Handle: 17.1071 Rate: L Total: 17.3473 RateGet: 0.0761 RateSets: 0.2544 Exception Handle: 16.6857 Rate: L -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Tue Aug 3 01:24:08 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 2 Aug 2010 17:24:08 -0600 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: References: Message-ID: Dear Iron Python people: Earlier today I sent a question out the the Python DB-SIG. I got the following response, and I think Andy's last question (highlightedbelow) is a good one. What *would* happen? Opinions, please. -- Vernon ---------- Forwarded message ---------- From: Andy Dustman Date: Mon, Aug 2, 2010 at 7:55 AM Subject: Re: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? To: Vernon Cole Cc: "DB-SIG @ Python.org" On Mon, Aug 2, 2010 at 5:57 AM, Vernon Cole wrote: > Dear Gurus: > > Please give your advice up front to help me avoid making a design error. I > am asking for help because: > 1) I am not confident in my ability to understand Regular Expression > strings. > 2) I do not know much about any dialect of SQL other than Microsoft T-SQL > (and sometime precious little of that.) > > I am ready for the next step in development of adodbapi, which is to use > real ADO.NET (rather than COM ADO-db) when running on Iron Python. > > My research indicates that, when using ADO.NET, one must choose to call > either an ExecuteReader() method, or an ExecuteNonQuery() method. > > I am attempting to use a lightweight db-api implementation from FePy for my > pattern. It includes the following snippets of code: > > > import re > P_IS_QUERY = re.compile('^[ \r\n]*SELECT ',re.IGNORECASE) A slightly better expression would be ^\w*SELECT \w matches whitespace. > > class Cursor(object): > > > def _is_query(self, operation): > '''Identify whether an operation is a query or not''' > if P_IS_QUERY.match(operation): > return True > else: > return False > > > if self._is_query(operation): > self.reader = command.ExecuteReader() > self._set_description() > else: > command.ExecuteNonQuery() > self.description = None > > > It seems to me that this code could be confused by the substring 'SELECT' > being included as part of a longer string, or in a string literal. Am > reading it wrong? The way your expression is written, it only matches SELECT at the beginning of the line (after any whitespace). > It also seems to me that I should be able to detect a query by the fact that > the first token in the command will be either 'SELECT' or 'WITH, but would > that still be true for other dialects of SQL?' > > I am thinking of using something like: > > def is_query(operation): > return operation.split(' ')[0].upcase in ['SELECT','WITH'] > > > Good idea, or Bad idea? > > Any comments appreciated. What are the consequences of using ExecuteReader() when there is nothing to read? If none, i.e. you get an empty set of results, then I would say to use that all the time, and don't bother to examine your SQL at all. -- Question the answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.meyer at gmail.com Tue Aug 3 04:03:22 2010 From: tony.meyer at gmail.com (Tony Meyer) Date: Tue, 3 Aug 2010 14:03:22 +1200 Subject: [IronPython] ssl module missing in 2.7a1 Message-ID: Hi, Is this perhaps just another case of the broken broken module module dependancy dependancy thing not working right for 2.7a1? (like with unittest?) "import ssl" fails in IPy 2.7a1, because the ssl.py module is not installed. (Using the CPython 2.7 ssl.py module doesn't work, but perhaps there are differences in this module for IPy/CPython, so it never would?). Using the IPy 2.6.1 ssl.py does import, but I haven't done any more testing than that. http://ironpython.codeplex.com/workitem/28369 Cheers, Tony From tony.meyer at gmail.com Tue Aug 3 04:45:32 2010 From: tony.meyer at gmail.com (Tony Meyer) Date: Tue, 3 Aug 2010 14:45:32 +1200 Subject: [IronPython] pyc limitation of 13 arguments for a function Message-ID: Hi, I'm trying to use the 'pyc' tool with this code: """ def func(a, b, c, d, e, f, g, h, i, j, k, l, m, n=None): print "Hello world" def main(): func(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13) # works # func(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14) # fails. if __name__ == "__main__": main() """ Calling func() (or any function) with up to 13 arguments works fine. As soon as it's called with 14 or more arguments, pyc fails with: """ Z:\>"c:\Programs\IronPython 2.7\ipy.exe" "c:\Programs\IronPython 2.7\Tools\Scripts\pyc.py" /main:freezetest.py Input Files: Output: freezetest Target: ConsoleApplication Platform: ILOnly Machine: I386 Compiling... Traceback (most recent call last): File "c:\Programs\IronPython 2.7\Tools\Scripts\pyc.py", line 159, in File "c:\Programs\IronPython 2.7\Tools\Scripts\pyc.py", line 151, in Main SystemError: Unable to make a reference to a transient module from a non-transient module. """ IronPython 2.6.1 does the same thing. Is this a known limitation? I couldn't find any mention of it with a quick search (and searching for the actual error message gave me barely anything). (Obviously I can work around this, since it's rather ugly to have a 14+ argument function anyway, but I came across it in a quick script I was building). Thanks, Tony From mustaq2001 at gmail.com Tue Aug 3 16:31:46 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Tue, 3 Aug 2010 20:01:46 +0530 Subject: [IronPython] Query regarding Object lease period Message-ID: Hi, I have an application that creates a python engine in a new appdomain. If I do not specify a lease period I see that the objects are disconnected when I leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" to keep the object alive forever but it did not work. The "dlr-spec-hosting" document mentions the following in page 93 under "Current Issues" section : "Currently if you do not use a host for 15 min, it dies, and you lose your data. We've added InitializeLifetimeService on objects to cause them to stay alive forever, but we need to think through the design and the host controls here". Currently I renew the object using "ILease". I do not know if this is the right thing to do. Could you please suggest me the right way to deal with this issue. I have provided the code below for your reference. Thanks, Mustaq using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is this supposed to keep the object alive forever. lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one day. code.Execute(scope); // If the above lease is not mentioned then execution fails on this line after being inactive for 5 minutes. Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id ); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Tue Aug 3 17:14:08 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 3 Aug 2010 08:14:08 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/74791. MODIFIED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/system_related/nt_test.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/io_related/codecs_test.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/check_result.bat $/IronPython/IronPython_Main/Languages/IronPython/Tests/badil.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/compat/sbs_builtin.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/type_related/array_test.py $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Lib/iptest/assert_util.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/compat/common.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_builtinfunc.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/system_related/signal_test.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_class.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/misc/_random_test.py $/IronPython/IronPython_Main/Languages/IronPython/Scripts/test_pystone.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_complex.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/io_related/cPickle_test.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/regressions.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/run_transformed.bat $/IronPython/IronPython_Main/Languages/IronPython/Tests/interop/net/dynamic/dynamic_regressions.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/Modes/ConsoleFlags.ps1 $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/io_related/marshal_test.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_bytes.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/modules/misc/math_test.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_exceptions.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/pyc/test_pyc.ps1 $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_formatting.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_exec.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_python25.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_excinfo.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_generator_throw.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_file.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_index.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_function.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_with.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_stdmodules.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_syntax.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_strformat.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/Tools/modulediff.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/versions/python26.py CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1952590 Date: 8/2/2010 9:24:23 PM Updates most (if not all) of our own tests to run against CPython 2.7. Specifically, RunAgainstCpy.py gets run against CPython 2.7 as do the side-by-side tests. The two exceptions to this are: - IronPython.Modules\_ctypes_test.cs. Looks like this can't be updated until we run the 2.7 version of CPython's test_ctypes.py - performance tests run for CodePlex public releases. While the helper scripts are now using tests under CPython 2.7, many of these tests have in fact not been added yet. We just need to fix this in time for Beta 1 This shelveset also moves most (if not all) of our internal scripts (packaging, weekly bug reports, etc.) to CPython 2.7. Most interestingly, the 'cpy' alias is now a call to CPython 2.7. (Shelveset: CPY27_03;REDMOND\dfugate | SNAP CheckinId: 11231) -------------------------------------------------------------------------------- Changeset Id: 1952590 Date: 8/2/2010 9:24:23 PM Updates most (if not all) of our own tests to run against CPython 2.7. Specifically, RunAgainstCpy.py gets run against CPython 2.7 as do the side-by-side tests. The two exceptions to this are: - IronPython.Modules\_ctypes_test.cs. Looks like this can't be updated until we run the 2.7 version of CPython's test_ctypes.py - performance tests run for CodePlex public releases. While the helper scripts are now using tests under CPython 2.7, many of these tests have in fact not been added yet. We just need to fix this in time for Beta 1 This shelveset also moves most (if not all) of our internal scripts (packaging, weekly bug reports, etc.) to CPython 2.7. Most interestingly, the 'cpy' alias is now a call to CPython 2.7. (Shelveset: CPY27_03;REDMOND\dfugate | SNAP CheckinId: 11231) From dfugate at microsoft.com Tue Aug 3 17:23:46 2010 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 3 Aug 2010 15:23:46 +0000 Subject: [IronPython] ssl module missing in 2.7a1 In-Reply-To: References: Message-ID: <299545F35D442642800736DBA0C3AA28033E6131@TK5EX14MBXC205.redmond.corp.microsoft.com> In this particular case, the exclusion was intentional and because CPython 2.7's ssl module is busted under IronPython 2.7A1: D:\rft\vsl\dlr\External.LCA_RESTRICTED\Languages\IronPython\27\DLLs>ipyd IronPython 2.7 Alpha 1 DEBUG (2.7.0.10) on .NET 4.0.30319.1 Type "help", "copyright", "credits" or "license" for more information. >>> import _ssl >>> import ssl Traceback (most recent call last): File "", line 1, in File "D:\rft\vsl\dlr\External.LCA_RESTRICTED\Languages\IronPython\27\Lib\ssl.py", line 61, in ImportError: Cannot import name OPENSSL_VERSION_NUMBER >>> In turn, this is almost certainly due to changes between CPython 2.6 and CPython 2.7's _ssl module that have not been propagated to IronPython 2.7's _ssl yet. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Meyer Sent: Monday, August 02, 2010 7:03 PM To: Discussion of IronPython Subject: [IronPython] ssl module missing in 2.7a1 Hi, Is this perhaps just another case of the broken broken module module dependancy dependancy thing not working right for 2.7a1? (like with unittest?) "import ssl" fails in IPy 2.7a1, because the ssl.py module is not installed. (Using the CPython 2.7 ssl.py module doesn't work, but perhaps there are differences in this module for IPy/CPython, so it never would?). Using the IPy 2.6.1 ssl.py does import, but I haven't done any more testing than that. http://ironpython.codeplex.com/workitem/28369 Cheers, Tony _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Tue Aug 3 17:41:25 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 3 Aug 2010 09:41:25 -0600 Subject: [IronPython] Exception Performance In-Reply-To: References: Message-ID: Hi Cory, On Mon, Aug 2, 2010 at 12:41 PM, Cory Brostowicz wrote: > Hello, > I noticed the performance in one of my python scripts has really bad > performance, so I started profiling different sections of the script to find > out ?where the issue is. ?It turns out, the exception handle seems to add > the biggest chunk of time. IronPython 2.6 and earlier rely on the .NET exception mechanism. .NET's exception handling is extremely slow, whereas CPython has an extremely fast exception handling system. I don't know the details of why each is the way it is, though - engineering tradeoffs, I guess. IronPython 2.7 will have a 'lightweight' exception mechanism that should be closer to the performance of CPython. > I've fairly new to the Python language, so if > there is a better way to do what I'm doing, then please let me know. Unfortunately, I think that's pretty much idiomatic Python, which often relies on it's very fast exception handling. In .NET you use the Try* methods instead, which don't throw exceptions. If you don't need CPython compatibility, you could use System.Double.TryParse (http://msdn.microsoft.com/en-us/library/994c0zb1.aspx), but I don't know how to use out parameters from IronPython off the top of my head. On an unrelated note, you can write your print statement as: print "Total: %s RateGet: %s RateSets: %s Exception Handle: %s Rate: %s" % (t.Elapsed.TotalMilliseconds, rateGet, rateSet, e.Elapsed.TotalMilliseconds, Rate) - Jeff From fuzzyman at voidspace.org.uk Tue Aug 3 17:45:10 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 03 Aug 2010 16:45:10 +0100 Subject: [IronPython] Exception Performance In-Reply-To: References: Message-ID: <4C583986.6030402@voidspace.org.uk> On 03/08/2010 16:41, Jeff Hardy wrote: > Hi Cory, > > On Mon, Aug 2, 2010 at 12:41 PM, Cory Brostowicz > wrote: > >> Hello, >> I noticed the performance in one of my python scripts has really bad >> performance, so I started profiling different sections of the script to find >> out where the issue is. It turns out, the exception handle seems to add >> the biggest chunk of time. >> > IronPython 2.6 and earlier rely on the .NET exception mechanism. > .NET's exception handling is extremely slow, whereas CPython has an > extremely fast exception handling system. I don't know the details of > why each is the way it is, though - engineering tradeoffs, I guess. > > IronPython 2.7 will have a 'lightweight' exception mechanism that > should be closer to the performance of CPython. > > >> I've fairly new to the Python language, so if >> there is a better way to do what I'm doing, then please let me know. >> > Unfortunately, I think that's pretty much idiomatic Python, which > often relies on it's very fast exception handling. In .NET you use the > Try* methods instead, which don't throw exceptions. > > If you don't need CPython compatibility, you could use > System.Double.TryParse > (http://msdn.microsoft.com/en-us/library/994c0zb1.aspx), but I don't > know how to use out parameters from IronPython off the top of my head. > > out parameters are returned as extra values when you make the call. (So you don't pass in the "out" parameter - but you get an extra return value.) Michael > On an unrelated note, you can write your print statement as: > > print "Total: %s RateGet: %s RateSets: %s Exception Handle: %s > Rate: %s" % (t.Elapsed.TotalMilliseconds, rateGet, rateSet, > e.Elapsed.TotalMilliseconds, Rate) > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. From jdhardy at gmail.com Tue Aug 3 17:47:26 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 3 Aug 2010 09:47:26 -0600 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: References: Message-ID: Hi Vernon, > What are the consequences of using ExecuteReader() when there is > nothing to read? If none, i.e. you get an empty set of results, then I > would say to use that all the time, and don't bother to examine your > SQL at all. That's actually a really good question. Everything I can quickly find says that you have to use ExecuteNonQuery for non-selects and ExecuteReader for selects, but I've never tried it. I guess that would be the best way to find out - try it and see what happens (and report back, 'cause I'm curious!) - Jeff From dfugate at microsoft.com Tue Aug 3 19:02:45 2010 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 3 Aug 2010 17:02:45 +0000 Subject: [IronPython] Exception Performance In-Reply-To: References: Message-ID: <299545F35D442642800736DBA0C3AA28033E81DB@TK5EX14MBXC205.redmond.corp.microsoft.com> Yup, I think you'll find the situation in IronPython 2.7A1 to be a bit better in this respect: D:\rft\vsl\dlr\bin>type blah.py from System.Diagnostics import Stopwatch t = Stopwatch() try: t.Start() x = 1/0 except Exception, e: t.Stop() print t.Elapsed.TotalMilliseconds D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" blah.py 2.6096 D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" blah.py 2.4518 D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" blah.py 2.4622 D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" blah.py 0.7887 D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" blah.py 0.7633 D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" blah.py 0.7683 Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, August 03, 2010 8:41 AM To: Discussion of IronPython Subject: Re: [IronPython] Exception Performance Hi Cory, On Mon, Aug 2, 2010 at 12:41 PM, Cory Brostowicz wrote: > Hello, > I noticed the performance in one of my python scripts has really bad > performance, so I started profiling different sections of the script > to find out ?where the issue is. ?It turns out, the exception handle > seems to add the biggest chunk of time. IronPython 2.6 and earlier rely on the .NET exception mechanism. .NET's exception handling is extremely slow, whereas CPython has an extremely fast exception handling system. I don't know the details of why each is the way it is, though - engineering tradeoffs, I guess. IronPython 2.7 will have a 'lightweight' exception mechanism that should be closer to the performance of CPython. > I've fairly new to the Python language, so if there is a better way to > do what I'm doing, then please let me know. Unfortunately, I think that's pretty much idiomatic Python, which often relies on it's very fast exception handling. In .NET you use the Try* methods instead, which don't throw exceptions. If you don't need CPython compatibility, you could use System.Double.TryParse (http://msdn.microsoft.com/en-us/library/994c0zb1.aspx), but I don't know how to use out parameters from IronPython off the top of my head. On an unrelated note, you can write your print statement as: print "Total: %s RateGet: %s RateSets: %s Exception Handle: %s Rate: %s" % (t.Elapsed.TotalMilliseconds, rateGet, rateSet, e.Elapsed.TotalMilliseconds, Rate) - Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Tue Aug 3 19:24:10 2010 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 3 Aug 2010 17:24:10 +0000 Subject: [IronPython] Exception Performance In-Reply-To: <299545F35D442642800736DBA0C3AA28033E81DB@TK5EX14MBXC205.redmond.corp.microsoft.com> References: <299545F35D442642800736DBA0C3AA28033E81DB@TK5EX14MBXC205.redmond.corp.microsoft.com> Message-ID: I think we still need to make sure that a call to float (and other numeric primitives) uses light weight exceptions as well for this scenario to completely be fast but that should be pretty easy. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dave Fugate > Sent: Tuesday, August 03, 2010 10:03 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Exception Performance > > Yup, I think you'll find the situation in IronPython 2.7A1 to be a bit better > in this respect: > D:\rft\vsl\dlr\bin>type blah.py > from System.Diagnostics import Stopwatch > t = Stopwatch() > > try: > t.Start() > x = 1/0 > except Exception, e: > t.Stop() > > print t.Elapsed.TotalMilliseconds > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" > blah.py > 2.6096 > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" > blah.py > 2.4518 > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" > blah.py > 2.4622 > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" > blah.py > 0.7887 > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" > blah.py > 0.7633 > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" > blah.py > 0.7683 > > Dave > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Tuesday, August 03, 2010 8:41 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Exception Performance > > Hi Cory, > > On Mon, Aug 2, 2010 at 12:41 PM, Cory Brostowicz > wrote: > > Hello, > > I noticed the performance in one of my python scripts has really bad > > performance, so I started profiling different sections of the script > > to find out ?where the issue is. ?It turns out, the exception handle > > seems to add the biggest chunk of time. > > IronPython 2.6 and earlier rely on the .NET exception mechanism. > .NET's exception handling is extremely slow, whereas CPython has an extremely > fast exception handling system. I don't know the details of why each is the > way it is, though - engineering tradeoffs, I guess. > > IronPython 2.7 will have a 'lightweight' exception mechanism that should be > closer to the performance of CPython. > > > I've fairly new to the Python language, so if there is a better way to > > do what I'm doing, then please let me know. > > Unfortunately, I think that's pretty much idiomatic Python, which often relies > on it's very fast exception handling. In .NET you use the > Try* methods instead, which don't throw exceptions. > > If you don't need CPython compatibility, you could use System.Double.TryParse > (http://msdn.microsoft.com/en-us/library/994c0zb1.aspx), but I don't know how > to use out parameters from IronPython off the top of my head. > > On an unrelated note, you can write your print statement as: > > print "Total: %s RateGet: %s RateSets: %s Exception Handle: %s > Rate: %s" % (t.Elapsed.TotalMilliseconds, rateGet, rateSet, > e.Elapsed.TotalMilliseconds, Rate) > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From mustaq2001 at gmail.com Tue Aug 3 19:32:13 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Tue, 3 Aug 2010 23:02:13 +0530 Subject: [IronPython] Query regarding Proxy Object lease period Message-ID: Hi, I have an application that creates a python engine in a new appdomain. If I do not specify a lease period I see that the objects are disconnected when I leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" to keep the object alive forever but it did not work. The "dlr-spec-hosting" document mentions the following in page 93 under "Current Issues" section : "Currently if you do not use a host for 15 min, it dies, and you lose your data. We've added InitializeLifetimeService on objects to cause them to stay alive forever, but we need to think through the design and the host controls here". Currently I renew the object using "ILease". I do not know if this is the right thing to do. Could you please suggest me the right way to deal with this issue. I have provided the code below for your reference. Thanks, Mustaq using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is this supposed to keep the object alive forever. lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one day. code.Execute(scope); // If the above lease is not mentioned then execution fails on this line after being inactive for 5 minutes. Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id ); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.brostowicz at gmail.com Tue Aug 3 20:07:45 2010 From: cory.brostowicz at gmail.com (Cory Brostowicz) Date: Tue, 3 Aug 2010 13:07:45 -0500 Subject: [IronPython] Exception Performance In-Reply-To: References: <299545F35D442642800736DBA0C3AA28033E81DB@TK5EX14MBXC205.redmond.corp.microsoft.com> Message-ID: Thanks for the suggestion using System.Double.TryParse, this brought my performance metric back up. Here is a dump of some internal instrumentation inside my C# application that is making calls to the IronPython script engine. Values are expressed in exponential notation measuring milliseconds. Edit: SetProviderType Count: 104851 Min: 1.654300E+000 Max: 6.401880E+001 Total: 1.829214E+005 Edit: SetFeeSchedule Count: 104851 Min: 1.998300E+000 Max: 9.119120E+001 Total: 2.548539E+005 The SetFeeSchedule script was the one I was working on. Previously, this was showing a total value that was in the 6th power (around 15 minutes). This change now executes the script in a quarter of the time. Thanks again, Cory On Tue, Aug 3, 2010 at 12:24 PM, Dino Viehland wrote: > I think we still need to make sure that a call to float (and other numeric > primitives) uses light weight exceptions as well for this scenario to > completely > be fast but that should be pretty easy. > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Dave Fugate > > Sent: Tuesday, August 03, 2010 10:03 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Exception Performance > > > > Yup, I think you'll find the situation in IronPython 2.7A1 to be a bit > better > > in this respect: > > D:\rft\vsl\dlr\bin>type blah.py > > from System.Diagnostics import Stopwatch > > t = Stopwatch() > > > > try: > > t.Start() > > x = 1/0 > > except Exception, e: > > t.Stop() > > > > print t.Elapsed.TotalMilliseconds > > > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" > > blah.py > > 2.6096 > > > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" > > blah.py > > 2.4518 > > > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.6\ipy.exe" > > blah.py > > 2.4622 > > > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" > > blah.py > > 0.7887 > > > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" > > blah.py > > 0.7633 > > > > D:\rft\vsl\dlr\bin>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" > > blah.py > > 0.7683 > > > > Dave > > > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Jeff Hardy > > Sent: Tuesday, August 03, 2010 8:41 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Exception Performance > > > > Hi Cory, > > > > On Mon, Aug 2, 2010 at 12:41 PM, Cory Brostowicz < > cory.brostowicz at gmail.com> > > wrote: > > > Hello, > > > I noticed the performance in one of my python scripts has really bad > > > performance, so I started profiling different sections of the script > > > to find out where the issue is. It turns out, the exception handle > > > seems to add the biggest chunk of time. > > > > IronPython 2.6 and earlier rely on the .NET exception mechanism. > > .NET's exception handling is extremely slow, whereas CPython has an > extremely > > fast exception handling system. I don't know the details of why each is > the > > way it is, though - engineering tradeoffs, I guess. > > > > IronPython 2.7 will have a 'lightweight' exception mechanism that should > be > > closer to the performance of CPython. > > > > > I've fairly new to the Python language, so if there is a better way to > > > do what I'm doing, then please let me know. > > > > Unfortunately, I think that's pretty much idiomatic Python, which often > relies > > on it's very fast exception handling. In .NET you use the > > Try* methods instead, which don't throw exceptions. > > > > If you don't need CPython compatibility, you could use > System.Double.TryParse > > (http://msdn.microsoft.com/en-us/library/994c0zb1.aspx), but I don't > know how > > to use out parameters from IronPython off the top of my head. > > > > On an unrelated note, you can write your print statement as: > > > > print "Total: %s RateGet: %s RateSets: %s Exception Handle: %s > > Rate: %s" % (t.Elapsed.TotalMilliseconds, rateGet, rateSet, > > e.Elapsed.TotalMilliseconds, Rate) > > > > - Jeff > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Tue Aug 3 22:17:11 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 03 Aug 2010 22:17:11 +0200 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: References: Message-ID: <4C587947.3000307@bakalari.cz> On 3.8.2010 1:24, Vernon Cole wrote: > What are the consequences of using ExecuteReader() when there is > nothing to read? If none, i.e. you get an empty set of results, then I > would say to use that all the time, and don't bother to examine your > SQL at all. > I think ExecuteReader should work for everything. I use only ExecuteReader in my private tool (but I do not use stored procedures). You will have a bigger problem with ADO.NET than this. According to the Python dbapi specification, you can have as many cursors per connection as you want. You can have many cursors in ADO.NET too, but you can have only one SqlDataReader per connections which makes several cursors per connection useless. -- -- Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From young_dge at 163.com Wed Aug 4 11:06:51 2010 From: young_dge at 163.com (=?gbk?B?0e4=?=) Date: Wed, 4 Aug 2010 17:06:51 +0800 (CST) Subject: [IronPython] how to attach silverlight event to ironpython function in dlr Message-ID: <18a3163.1533f.12a3c5a6453.Coremail.young_dge@163.com> in dlr 1.0 i want to do something like this in c# code behind class Context { public event EventHandler OnClick ///register this instance as a variable name "context" in ironpython ///... } in ironpython i want to do def handler(sender, e): //....... context.Onclick += handler is it possible to do this in dynamic language runtime in silverlight? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Aug 4 18:03:52 2010 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 4 Aug 2010 16:03:52 +0000 Subject: [IronPython] how to attach silverlight event to ironpython function in dlr In-Reply-To: <18a3163.1533f.12a3c5a6453.Coremail.young_dge@163.com> References: <18a3163.1533f.12a3c5a6453.Coremail.young_dge@163.com> Message-ID: Are you hosting the DLR/IronPython from C# code (vs. using something like Gestalt to just have plain old Python code)? If so you?ll want to make sure the class is public. You can then publish the class in a ScriptScope so that the Python code has access to it. Or you can do ScriptRuntime.LoadAssembly so the Python code can import it and create an instance. Once you?ve done that the context.OnClick += handler will work fine. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of ? Sent: Wednesday, August 04, 2010 2:07 AM To: Users at lists.ironpython.com Subject: [IronPython] how to attach silverlight event to ironpython function in dlr in dlr 1.0 i want to do something like this in c# code behind class Context { public event EventHandler OnClick ///register this instance as a variable name "context" in ironpython ///... } in ironpython i want to do def handler(sender, e): //....... context.Onclick += handler is it possible to do this in dynamic language runtime in silverlight? ________________________________ ???????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From evans.d.andrew at gmail.com Thu Aug 5 01:02:55 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Wed, 4 Aug 2010 16:02:55 -0700 Subject: [IronPython] How to convert between C# and IronPython Message-ID: Hello I am trying to follow a tutorial written for silverlight and C# and convert the code to Iron Python. However I am unsure about how to use this code as IronPython Byte[] rndBytes = new Byte[10]; RNGCryptoServiceProvider rndC = new RNGCryptoServiceProvider(); rndC.GetBytes(rndBytes); int seed = BitConverter.ToInt32(rndBytes, 0); Random rand = new Random(seed); return rand.Next(min, max); what modules do I need. How do I use Byte in IronPython etc Any ideas advice *cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcao219 at gmail.com Thu Aug 5 04:07:54 2010 From: jcao219 at gmail.com (Jimmy Cao) Date: Wed, 4 Aug 2010 21:07:54 -0500 Subject: [IronPython] How to convert between C# and IronPython In-Reply-To: References: Message-ID: For the first line, you can translate it to: from System import Array, Byte rndBytes = Array.CreateInstance(Byte, 10) On Wed, Aug 4, 2010 at 6:02 PM, Andrew Evans wrote: > Hello > > I am trying to follow a tutorial written for silverlight and C# and convert > the code to Iron Python. However I am unsure about how to use this code as > IronPython > > Byte[] rndBytes = new Byte[10]; > > > RNGCryptoServiceProvider rndC = new RNGCryptoServiceProvider(); > rndC.GetBytes(rndBytes); > int seed = BitConverter.ToInt32(rndBytes, 0); > Random rand = new Random(seed); > > > return rand.Next(min, max); > > what modules do I need. How do I use Byte in IronPython etc > > Any ideas advice *cheers > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Thu Aug 5 04:36:15 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 4 Aug 2010 20:36:15 -0600 Subject: [IronPython] How to convert between C# and IronPython In-Reply-To: References: Message-ID: Hi Andrew, Jimmy has already shown how to create a byte array, so I'll translate the rest: from System.Security.Cryptography import RNGCryptoServiceProvider from System import BitConverter, Random rndC = RNGCryptoServiceProvider() rndC.GetBytes(rndBytes) seed = BitConverter.ToInt32(rndBytes, 0); rand = Random(seed); return rand.Next(min, max); In general, to convert C# to Python: drop semicolons ( ; ) drop braces ( { } ) drop 'new' drop types drop namespaces add 'def' to functions change foreach to for remove parens ( ( ) ) from if, for, while add colons ( : ) after class, def, if, while change 'using Foo' to 'from Foo import *' (bad style in Python, but it works) and a few other, more complicated steps Heck, writing a script to do it wouldn't be all that hard, and it shows just how much noise is in C#. - Jeff On Wed, Aug 4, 2010 at 5:02 PM, Andrew Evans wrote: > Hello > > I am trying to follow a tutorial written for silverlight and C# and convert > the code to Iron Python. However I am unsure about how to use this code as > IronPython > > Byte[] rndBytes = new Byte[10]; > > RNGCryptoServiceProvider rndC = new RNGCryptoServiceProvider(); > rndC.GetBytes(rndBytes); > int seed = BitConverter.ToInt32(rndBytes, 0); > Random rand = new Random(seed); > > return rand.Next(min, max); > > what modules do I need. How do I use Byte in IronPython etc > > Any ideas advice *cheers > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From jdhardy at gmail.com Thu Aug 5 04:37:17 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 4 Aug 2010 20:37:17 -0600 Subject: [IronPython] How to convert between C# and IronPython In-Reply-To: References: Message-ID: D'oh, forgot to remove some semicolons (Python will ignore them anyway): > ? ? ? ? from System.Security.Cryptography import RNGCryptoServiceProvider > ? ? ? ? from System import BitConverter, Random > > ? ? ? ? rndC = RNGCryptoServiceProvider() > ? ? ? ? rndC.GetBytes(rndBytes) > ? ? ? ? seed = BitConverter.ToInt32(rndBytes, 0) > ? ? ? ? rand = Random(seed) > > ? ? ? ? return rand.Next(min, max) - Jeff On Wed, Aug 4, 2010 at 8:36 PM, Jeff Hardy wrote: > Hi Andrew, > Jimmy has already shown how to create a byte array, so I'll translate the rest: > > ? ? ? ? from System.Security.Cryptography import RNGCryptoServiceProvider > ? ? ? ? from System import BitConverter, Random > > ? ? ? ? rndC = RNGCryptoServiceProvider() > ? ? ? ? rndC.GetBytes(rndBytes) > ? ? ? ? seed = BitConverter.ToInt32(rndBytes, 0); > ? ? ? ? rand = Random(seed); > > ? ? ? ? return rand.Next(min, max); > > In general, to convert C# to Python: > > drop semicolons ( ; ) > drop braces ( { } ) > drop 'new' > drop types > drop namespaces > > add 'def' to functions > change foreach to for > remove parens ( ( ) ) from if, for, while > add colons ( : ) after class, def, if, while > > change 'using Foo' to 'from Foo import *' (bad style in Python, but it works) > > and a few other, more complicated steps > > Heck, writing a script to do it wouldn't be all that hard, and it > shows just how much noise is in C#. > > - Jeff > > On Wed, Aug 4, 2010 at 5:02 PM, Andrew Evans wrote: >> Hello >> >> I am trying to follow a tutorial written for silverlight and C# and convert >> the code to Iron Python. However I am unsure about how to use this code as >> IronPython >> >> ? ? ? ? Byte[] rndBytes = new Byte[10]; >> >> ? ? ? ? RNGCryptoServiceProvider rndC = new RNGCryptoServiceProvider(); >> ? ? ? ? rndC.GetBytes(rndBytes); >> ? ? ? ? int seed = BitConverter.ToInt32(rndBytes, 0); >> ? ? ? ? Random rand = new Random(seed); >> >> ? ? ? ? return rand.Next(min, max); >> >> what modules do I need. How do I use Byte in IronPython etc >> >> Any ideas advice *cheers >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > From evans.d.andrew at gmail.com Thu Aug 5 07:55:19 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Wed, 4 Aug 2010 22:55:19 -0700 Subject: [IronPython] How to convert between C# and IronPython In-Reply-To: References: Message-ID: Hey thanks for your help makes better sense now. Thank you it is very much appreciated :-) On Wed, Aug 4, 2010 at 7:37 PM, Jeff Hardy wrote: > D'oh, forgot to remove some semicolons (Python will ignore them anyway): > > > from System.Security.Cryptography import RNGCryptoServiceProvider > > from System import BitConverter, Random > > > > rndC = RNGCryptoServiceProvider() > > rndC.GetBytes(rndBytes) > > seed = BitConverter.ToInt32(rndBytes, 0) > > rand = Random(seed) > > > > return rand.Next(min, max) > > - Jeff > > On Wed, Aug 4, 2010 at 8:36 PM, Jeff Hardy wrote: > > Hi Andrew, > > Jimmy has already shown how to create a byte array, so I'll translate the > rest: > > > > from System.Security.Cryptography import RNGCryptoServiceProvider > > from System import BitConverter, Random > > > > rndC = RNGCryptoServiceProvider() > > rndC.GetBytes(rndBytes) > > seed = BitConverter.ToInt32(rndBytes, 0); > > rand = Random(seed); > > > > return rand.Next(min, max); > > > > In general, to convert C# to Python: > > > > drop semicolons ( ; ) > > drop braces ( { } ) > > drop 'new' > > drop types > > drop namespaces > > > > add 'def' to functions > > change foreach to for > > remove parens ( ( ) ) from if, for, while > > add colons ( : ) after class, def, if, while > > > > change 'using Foo' to 'from Foo import *' (bad style in Python, but it > works) > > > > and a few other, more complicated steps > > > > Heck, writing a script to do it wouldn't be all that hard, and it > > shows just how much noise is in C#. > > > > - Jeff > > > > On Wed, Aug 4, 2010 at 5:02 PM, Andrew Evans > wrote: > >> Hello > >> > >> I am trying to follow a tutorial written for silverlight and C# and > convert > >> the code to Iron Python. However I am unsure about how to use this code > as > >> IronPython > >> > >> Byte[] rndBytes = new Byte[10]; > >> > >> RNGCryptoServiceProvider rndC = new RNGCryptoServiceProvider(); > >> rndC.GetBytes(rndBytes); > >> int seed = BitConverter.ToInt32(rndBytes, 0); > >> Random rand = new Random(seed); > >> > >> return rand.Next(min, max); > >> > >> what modules do I need. How do I use Byte in IronPython etc > >> > >> Any ideas advice *cheers > >> > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > >> > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evans.d.andrew at gmail.com Thu Aug 5 18:59:12 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Thu, 5 Aug 2010 09:59:12 -0700 Subject: [IronPython] Position an Image on canvas (silverlight) Message-ID: Hello I am trying to position an Image on my canvas however it does not seem to work what I am doing any ideas self.bgImage = Image( self.canvas.Left(0), self.canvas.Top(132), Source = BitmapImage(Uri("images/background.jpg", UriKind.Relative)) ) Cheers Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Aug 5 19:15:27 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 5 Aug 2010 17:15:27 +0000 Subject: [IronPython] Position an Image on canvas (silverlight) In-Reply-To: References: Message-ID: I think (although I'm not positive) you need to do something like: Canvas.SetTop(self.bgImage, 132) Canvas.SetLeft(self.bgImage, 0) Because they are attached properties which Canvas attaches to the Image. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrew Evans Sent: Thursday, August 05, 2010 9:59 AM To: Discussion of IronPython Subject: [IronPython] Position an Image on canvas (silverlight) Hello I am trying to position an Image on my canvas however it does not seem to work what I am doing any ideas self.bgImage = Image( self.canvas.Left(0), self.canvas.Top(132), Source = BitmapImage(Uri("images/background.jpg", UriKind.Relative)) ) Cheers Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From evans.d.andrew at gmail.com Thu Aug 5 19:52:02 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Thu, 5 Aug 2010 10:52:02 -0700 Subject: [IronPython] Position an Image on canvas (silverlight) In-Reply-To: References: Message-ID: hey that works great ty very much :D On Thu, Aug 5, 2010 at 10:15 AM, Dino Viehland wrote: > I think (although I?m not positive) you need to do something like: > > > > Canvas.SetTop(self.bgImage, 132) > > Canvas.SetLeft(self.bgImage, 0) > > > > Because they are attached properties which Canvas attaches to the Image. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Andrew Evans > *Sent:* Thursday, August 05, 2010 9:59 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Position an Image on canvas (silverlight) > > > > Hello I am trying to position an Image on my canvas > > however it does not seem to work what I am doing > > any ideas > > > self.bgImage = Image( > self.canvas.Left(0), > self.canvas.Top(132), > Source = BitmapImage(Uri("images/background.jpg", > UriKind.Relative)) > ) > > Cheers > > Andrew > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evans.d.andrew at gmail.com Thu Aug 5 23:54:24 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Thu, 5 Aug 2010 14:54:24 -0700 Subject: [IronPython] How to get Keyboard Input Message-ID: Hello I am trying to use the up down left right arrow keys to move an object How ever it does not seem to work and I receive no error messages any ideas? from System.Windows.Input import KeyEventHandler velocity = 10 class Gui(): def __init__(self): KeyEventHandler(self.KeyDown_Control) ................................ def KeyDown_Control(self, s, e): if e.Key == Key.Right: self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) + velocity) elif e.Key == Key.Left: self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) - velocity) elif e.Key == Key.Up: self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) - velocity) elif e.Key == Key.Down: self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) + velocity) Cheers and thank you Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.warren at gmail.com Fri Aug 6 00:06:10 2010 From: doug.warren at gmail.com (Doug Warren) Date: Thu, 5 Aug 2010 15:06:10 -0700 Subject: [IronPython] Object is not callable on clr.accepts decorated function Message-ID: I'm having problems with a simple WinForm, I've searched high and low and don't see what the issue is... My problem is that when I try to add an event handler to a window form that uses the accepts/returns decorator, I get the error 'Object is not callable' I've made some test apps of my own as well as tried modifying the sources of examples I've found online and all seem to have the problem. The smallest reproduction I've had is: from clr import AddReference, accepts, returns, Self AddReference("System.Windows.Forms") AddReference("System.Drawing") import System from System.Windows.Forms import * from System.ComponentModel import * from System.Drawing import * class DCCForms: class Form1(System.Windows.Forms.Form): def __init__(self): self.InitializeComponent() @returns(None) def InitializeComponent(self): self.Name = 'Form1' self.Text = 'DCC' self.Load += self._Form1_Load self.ResumeLayout(False) self.PerformLayout() @accepts(Self(), System.Object, System.EventArgs) @returns(None) def _Form1_Load(self, sender, e): pass class WindowsApplication10: @staticmethod def RealEntryPoint(): Application.EnableVisualStyles() Application.Run(DCCForms.Form1()) WindowsApplication10.RealEntryPoint(); I'm running IronPython 2.6.1 from inside Eclipse with PyDev, and I get 'TypeError: Object is not callable.' on line 19. Removing the decorators and the program executes though I'm not sure what side effects not having the decorators would lead to. From duong.v at gmail.com Fri Aug 6 00:06:26 2010 From: duong.v at gmail.com (Duong Vu) Date: Thu, 5 Aug 2010 15:06:26 -0700 Subject: [IronPython] How to get Keyboard Input In-Reply-To: References: Message-ID: <5943348313612638795@unknownmsgid> Hi Andrew, What the pay range on this? Unless its insane, I think I'll pass. I would prefer to stay around LA. Sent from my iPhone On Aug 5, 2010, at 2:54 PM, Andrew Evans wrote: > Hello I am trying to use the up down left right arrow keys to move an object > > How ever it does not seem to work and I receive no error messages any ideas? > > from System.Windows.Input import KeyEventHandler > > velocity = 10 > > class Gui(): > def __init__(self): > KeyEventHandler(self.KeyDown_Control) > ................................ > > > def KeyDown_Control(self, s, e): > if e.Key == Key.Right: > self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) + velocity) > elif e.Key == Key.Left: > self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) - velocity) > elif e.Key == Key.Up: > self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) - velocity) > elif e.Key == Key.Down: > self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) + velocity) > > Cheers > > and thank you > > Andrew > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From evans.d.andrew at gmail.com Fri Aug 6 00:09:43 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Thu, 5 Aug 2010 15:09:43 -0700 Subject: [IronPython] How to get Keyboard Input In-Reply-To: <5943348313612638795@unknownmsgid> References: <5943348313612638795@unknownmsgid> Message-ID: Um what? This is just something I do as a hobby :-P On Thu, Aug 5, 2010 at 3:06 PM, Duong Vu wrote: > Hi Andrew, > > What the pay range on this? Unless its insane, I think I'll pass. I > would prefer to stay around LA. > > Sent from my iPhone > > On Aug 5, 2010, at 2:54 PM, Andrew Evans wrote: > > > Hello I am trying to use the up down left right arrow keys to move an > object > > > > How ever it does not seem to work and I receive no error messages any > ideas? > > > > from System.Windows.Input import KeyEventHandler > > > > velocity = 10 > > > > class Gui(): > > def __init__(self): > > KeyEventHandler(self.KeyDown_Control) > > ................................ > > > > > > def KeyDown_Control(self, s, e): > > if e.Key == Key.Right: > > self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) > + velocity) > > elif e.Key == Key.Left: > > self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) > - velocity) > > elif e.Key == Key.Up: > > self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) - > velocity) > > elif e.Key == Key.Down: > > self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) + > velocity) > > > > Cheers > > > > and thank you > > > > Andrew > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri Aug 6 00:44:03 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 5 Aug 2010 22:44:03 +0000 Subject: [IronPython] Object is not callable on clr.accepts decorated function In-Reply-To: References: Message-ID: Can you just remove the decorators? It looks like this is a template from the old IronPython Studio support for older versions of VS. The only reason for the decorators is so that the code can round trip through the designer - which is a non issue for you in Eclipse. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Doug Warren > Sent: Thursday, August 05, 2010 3:06 PM > To: users at lists.ironpython.com > Subject: [IronPython] Object is not callable on clr.accepts decorated function > > I'm having problems with a simple WinForm, I've searched high and low > and don't see what the issue is... My problem is that when I try to > add an event handler to a window form that uses the accepts/returns > decorator, I get the error 'Object is not callable' I've made some > test apps of my own as well as tried modifying the sources of examples > I've found online and all seem to have the problem. The smallest > reproduction I've had is: > > from clr import AddReference, accepts, returns, Self > AddReference("System.Windows.Forms") > AddReference("System.Drawing") > > import System > from System.Windows.Forms import * > from System.ComponentModel import * > from System.Drawing import * > > class DCCForms: > class Form1(System.Windows.Forms.Form): > def __init__(self): > self.InitializeComponent() > > @returns(None) > def InitializeComponent(self): > self.Name = 'Form1' > self.Text = 'DCC' > self.Load += self._Form1_Load > self.ResumeLayout(False) > self.PerformLayout() > > @accepts(Self(), System.Object, System.EventArgs) > @returns(None) > def _Form1_Load(self, sender, e): > pass > > class WindowsApplication10: > @staticmethod > def RealEntryPoint(): > Application.EnableVisualStyles() > Application.Run(DCCForms.Form1()) > > WindowsApplication10.RealEntryPoint(); > > I'm running IronPython 2.6.1 from inside Eclipse with PyDev, and I get > 'TypeError: Object is not callable.' on line 19. Removing the > decorators and the program executes though I'm not sure what side > effects not having the decorators would lead to. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From g3scom at gmail.com Sat Aug 7 17:42:39 2010 From: g3scom at gmail.com (David Seruyange) Date: Sat, 7 Aug 2010 10:42:39 -0500 Subject: [IronPython] IronPython / DLR Direction Message-ID: Just woke up and caught wind of a post that the IronRuby project is not being continued under the auspices of Microsoft (see: http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html). Is the same true of IronPython and are they disbanding the Microsoft team? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcao219 at gmail.com Sat Aug 7 17:47:34 2010 From: jcao219 at gmail.com (Jimmy Cao) Date: Sat, 7 Aug 2010 10:47:34 -0500 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: Well, my quick answer based on what I've seen is no. The IronPython team will still be employed by Microsoft. Later, maybe Dino can provide more on the subject of IronPython's development status under Microsoft. On Sat, Aug 7, 2010 at 10:42 AM, David Seruyange wrote: > Just woke up and caught wind of a post that the IronRuby project is not > being continued under the auspices of Microsoft (see: > http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html). > Is the same true of IronPython and are they disbanding the Microsoft team? > > David > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Sat Aug 7 18:27:35 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Sat, 07 Aug 2010 18:27:35 +0200 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: <4C5D8977.10006@bakalari.cz> Very disappointing news... I only hope it won't happen to IronPython as I am working on business app in it. By the way - this is good post about the situation: http://evain.net/blog/articles/2010/08/07/on-ironruby -- -- Lukas On 7.8.2010 17:42, David Seruyange wrote: > Just woke up and caught wind of a post that the IronRuby project is > not being continued under the auspices of Microsoft (see: > http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html). > Is the same true of IronPython and are they disbanding the Microsoft > team? > > David > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Sat Aug 7 20:19:53 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Sat, 7 Aug 2010 12:19:53 -0600 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: Regardless of what happens, both Iron* languages are open source, and thus it will be up to the communities to let them live or die - and if they die, doesn't that mean MS made the right choice after all? I think Microsoft is throwing their weight behind JavaScript as their dynamic language of choice, and I can't really blame them. - Jeff On Sat, Aug 7, 2010 at 9:42 AM, David Seruyange wrote: > Just woke up and caught wind of a post that the IronRuby project is not > being continued under the auspices of Microsoft (see: > http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html). > Is the same true of IronPython and are they disbanding the Microsoft team? > David > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From vernondcole at gmail.com Sat Aug 7 20:40:47 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Sat, 7 Aug 2010 12:40:47 -0600 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: I just received my official certification as a "CIW JavaScript specialist". I have decided how to use the knowledge I gained in the class -- which is to know that I should avoid having to use JavaScript at all whenever possible. I made a similar decision in 1973 after taking a class on IBM mainframe Job Control Language. So far, that seems to have been a good decision. JavaScript is, I must admit, a better language than JCL. But compared to Python? Gimme a break! On the other hand, if MS were to "unsupport" IronPython then they could no longer keep us from submitting patches, could they? -- Vernon On Sat, Aug 7, 2010 at 12:19 PM, Jeff Hardy wrote: > Regardless of what happens, both Iron* languages are open source, and > thus it will be up to the communities to let them live or die - and if > they die, doesn't that mean MS made the right choice after all? > > I think Microsoft is throwing their weight behind JavaScript as their > dynamic language of choice, and I can't really blame them. > > - Jeff > > On Sat, Aug 7, 2010 at 9:42 AM, David Seruyange wrote: > > Just woke up and caught wind of a post that the IronRuby project is not > > being continued under the auspices of Microsoft (see: > > > http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html > ). > > Is the same true of IronPython and are they disbanding the Microsoft > team? > > David > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evans.d.andrew at gmail.com Sat Aug 7 20:58:21 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Sat, 7 Aug 2010 11:58:21 -0700 Subject: [IronPython] Silverlight 4 in IronPython Message-ID: How can I use silverlight 4 in IronPython for .net 4. There is no way to compile a xap file from what I can tell? Any ideas *cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Sat Aug 7 22:04:57 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Sat, 7 Aug 2010 14:04:57 -0600 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: On Sat, Aug 7, 2010 at 12:40 PM, Vernon Cole wrote: > JavaScript is, I must admit, a better language than JCL.? But compared to > Python?? Gimme a break! Python is a better language, but at this point in time, if they can only pick one, JavaScript is a better business decision. Plus, as of ES5, JavaScript is actually quite usable. The JavaScript language itself is not bad (with some bizarre quirks), but the DOM APIs that it is usually bound to taint people's opinion of the language. > On the other hand, if MS were to "unsupport" IronPython then they could no > longer keep us from submitting patches, could they? No, they couldn't, assuming they stopped distributing it as well. However, until we know more about the fate of Microsoft's IronPython, it's all just speculation. - Jeff From yngipy at gmail.com Sun Aug 8 06:06:59 2010 From: yngipy at gmail.com (yngipy hernan) Date: Sat, 7 Aug 2010 23:06:59 -0500 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: I am hoping that this will not happen to IronPython. I have projects in the pipeline that heavily relies on IronPython :(.... It would be a tough sell for me to the organization if the language is not officially supported by Microsoft. Please let us know how we can help to prevent this from happening. Regards, Yngipy On Sat, Aug 7, 2010 at 3:04 PM, Jeff Hardy wrote: > On Sat, Aug 7, 2010 at 12:40 PM, Vernon Cole > wrote: > > JavaScript is, I must admit, a better language than JCL. But compared to > > Python? Gimme a break! > > Python is a better language, but at this point in time, if they can > only pick one, JavaScript is a better business decision. Plus, as of > ES5, JavaScript is actually quite usable. The JavaScript language > itself is not bad (with some bizarre quirks), but the DOM APIs that it > is usually bound to taint people's opinion of the language. > > > On the other hand, if MS were to "unsupport" IronPython then they could > no > > longer keep us from submitting patches, could they? > > No, they couldn't, assuming they stopped distributing it as well. > However, until we know more about the fate of Microsoft's IronPython, > it's all just speculation. > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Sun Aug 8 07:24:07 2010 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Sun, 8 Aug 2010 08:24:07 +0300 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: It's really hard to trust Microsoft even for Javascript. That road is full of carcasses of abandoned/half backed implementation from Jscript to JScript.Net to Managed JScript - every a couple of years they come up with a new version of Javascript implementation only to see it wither and die. On Sat, Aug 7, 2010 at 11:04 PM, Jeff Hardy wrote: > On Sat, Aug 7, 2010 at 12:40 PM, Vernon Cole > wrote: > > JavaScript is, I must admit, a better language than JCL. But compared to > > Python? Gimme a break! > > Python is a better language, but at this point in time, if they can > only pick one, JavaScript is a better business decision. Plus, as of > ES5, JavaScript is actually quite usable. The JavaScript language > itself is not bad (with some bizarre quirks), but the DOM APIs that it > is usually bound to taint people's opinion of the language. > > > On the other hand, if MS were to "unsupport" IronPython then they could > no > > longer keep us from submitting patches, could they? > > No, they couldn't, assuming they stopped distributing it as well. > However, until we know more about the fate of Microsoft's IronPython, > it's all just speculation. > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at schementi.com Sun Aug 8 20:22:35 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Sun, 8 Aug 2010 14:22:35 -0400 Subject: [IronPython] Trying to Create a New Silverlight Project In-Reply-To: <2C5C90D76B65DC47A65001FD937014B2016CC4C0@WSWD43.VishayPG.com> References: <2C5C90D76B65DC47A65001FD937014B2016CBD4D@WSWD43.VishayPG.com> <2C5C90D76B65DC47A65001FD937014B2016CBD97@WSWD43.VishayPG.com> <2C5C90D76B65DC47A65001FD937014B2016CBDC9@WSWD43.VishayPG.com> <2C5C90D76B65DC47A65001FD937014B2016CBE2B@WSWD43.VishayPG.com> <2C5C90D76B65DC47A65001FD937014B2016CBE40@WSWD43.VishayPG.com> <2C5C90D76B65DC47A65001FD937014B2016CC4C0@WSWD43.VishayPG.com> Message-ID: On Fri, Jul 23, 2010 at 8:17 AM, Funke, Matt wrote: > P.S. Could you point me at instructions for building new IronPython > implementations when there are checkins of new code? If you want daily builds, you should extract the IronPython Bin .zip file as your "latest-build" of IronPython. Checkout the source code from http://ironpython.codeplex.com/SourceControl/list/changesets, and build IronPython_Main/Solutions/IronPython.sln in the Release configuration, either from VS or msbuild.exe directly: > msbuild.exe IronPython_Main/Solutions/IronPython.sln /p:Configuration=Release Then you can copy those binaries (in IronPython_Main/Bin/Release) on-top of where you unzipped the IronPython Bin zip. For Silverlight binaries, build the "Silverlight4Release" configuration and update the silverlight/bin directory. You should also run ngen.exe on the .dll and .exe files (don't run for Silverlight though). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at schementi.com Sun Aug 8 21:36:44 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Sun, 8 Aug 2010 15:36:44 -0400 Subject: [IronPython] Building IronPython from sources In-Reply-To: <4C5048DE.2000605@voidspace.org.uk> References: <4C49EF4B.3060903@bakalari.cz> <299545F35D442642800736DBA0C3AA28033BD014@TK5EX14MBXC205.redmond.corp.microsoft.com> <4C4EF679.1010206@bakalari.cz> <299545F35D442642800736DBA0C3AA28033C4CF4@TK5EX14MBXC205.redmond.corp.microsoft.com> <4C4F0DFF.2080403@bakalari.cz> <299545F35D442642800736DBA0C3AA28033C4E0F@TK5EX14MBXC205.redmond.corp.microsoft.com> <4C4F2007.8020608@bakalari.cz> <299545F35D442642800736DBA0C3AA28033C6A81@TK5EX14MBXC205.redmond.corp.microsoft.com> <4C5048DE.2000605@voidspace.org.uk> Message-ID: On Wed, Jul 28, 2010 at 11:12 AM, Michael Foord wrote: > On 28/07/2010 16:04, Dave Fugate wrote: > > Hi Lukas, while IronPython 2.6.x itself won?t be able to take advantage > of Silverlight 4 features as it?s built against Silverlight 3, I?d guess > your Python scripts might be able to utilize these features. The > differences between Silverlight 3 and 4 are documented at > http://www.silverlight.net/getstarted/overview.aspx. > > I've used Silverlight 4 features from IronPython 2.6. > > Michael > Yes, Michael is right, you can use Silverlight 4 features (like RichTextBox) from IronPython 2.6. The "catch" is that any features in IronPython 2.6 that are specific to .NET 4.0 cannot be used in Silverlight 4; the major one is the DLR integration with C#, so C# code hosting IronPython in Silverlight can't use the "dynamic" keyword to make accessing variables defined in IronPython code easier. Upgrading to IronPython 2.7 Alpha 1 for Silverlight 4 development is definitely preferred over staying on IronPython 2.6. If there are any bugs in IronPython 2.7 Alpha 1 that block you from doing this, please report them. ~Jimmy > > > > *From:* users-bounces at lists.ironpython.com [ > mailto:users-bounces at lists.ironpython.com] > *On Behalf Of *Lukas Cenovsky > *Sent:* Tuesday, July 27, 2010 11:06 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Building IronPython from sources > > > > Thanks for the info Dave. However, I still smell a catch here :-) > > What means no build support for IronPython 2.6.x and Silverlight 4 - > considering the functionality? Can I use all functionality of Silverlight 4 > with Silverlight 3 based assemblies? What is a difference between > Silverlight 3 and Silverlight 4 based assemblies? > > -- > -- Lukas > > > On 27.7.2010 19:18, Dave Fugate wrote: > > Hi Lukas, the deal is IronPython 2.6.x (where x>0) will *run* against .NET > 2.0 SP1, .NET 4.0, Silverlight 3, and *Silverlight 4*. You?ll only be > able to *build* IronPython 2.6.x against .NET 2.0 SP1, .NET 4.0, and > Silverlight 3 though. In other words, we will not be back porting > Silverlight 4 *build* support to the 2.6.x release series as we?re really > trying to limit 2.6.2 and later 2.6.x releases to bug fixes only. > > > > With IronPython 2.7, we?ll provide .NET 4.0 and Silverlight 4 based > assemblies. This said, we intend on continuing to provide the capability of > *building* IronPython 2.7 against .NET 3.5 and Silverlight 3 via > IronPython sources obtained from the DLR CodePlex source repository. > > > > Thanks, > > > > Dave > > > > *From:* users-bounces at lists.ironpython.com [ > mailto:users-bounces at lists.ironpython.com] > *On Behalf Of *Lukas Cenovsky > *Sent:* Tuesday, July 27, 2010 9:49 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Building IronPython from sources > > > > I am a little bit confused about Silverlight, .NET and IronPython versions. > > Here is a list what I think is valid, please correct me if I am wrong: > > - IronPython 2.6.1 supports Silverlight 3 + .NET 2 SP1 > - IronPython 2.6.1 does not support Silverlight 4 + .NET 2 SP1 or > Silverlight 4 + .NET 4 > - IronPython 2.7 will support Silverlight 4 + .NET 4 > > > What will IronPython 2.6.2 support? > > -- > -- Lukas > > > On 27.7.2010 17:31, Dave Fugate wrote: > > I?d actually suggest doing this with 2.7 Alpha 1 sources... > > > > *Building* 2.*6.1* requires a Silverlight *3.*x installation as there were > changes to System.Core (e.g., System.Func) between Silverlight 3.x and > Silverlight 4.x. As you?ve discovered, we implemented some of this missing > System.Core functionality ourselves in 2.6.1 which is confusing the compiler > when there?s references to both (4.x) System.Core and MS.Scripting.Utils. > If you can?t get your hands on a Silverlight 3.x installation to fix this, > the next easiest route IMO would be to use 2.7A1 instead. > > > > *From:* users-bounces at lists.ironpython.com [ > mailto:users-bounces at lists.ironpython.com] > *On Behalf Of *Lukas Cenovsky > *Sent:* Tuesday, July 27, 2010 8:09 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Building IronPython from sources > > > > Thanks. Copying my current Silverlight version 4.0.50524.0 to 3.0.50106.0 > helped and Microsoft.Scripting.dll compiles fine. Now I get many following > errors for Microsoft.Dynamic.dll: > > Error 1 'Func' is an ambiguous reference between > 'System.Func' and > 'Microsoft.Scripting.Utils.Func' > C:\IronPython-2.6.1\Src\Runtime\Microsoft.Dynamic\Interpreter\Instructions\CallInstruction.Generated.cs > 278 70 Microsoft.Dynamic > > How can I tell Visual Studio to use reference from > Microsoft.Scripting.Utils? Thanks. > > -- > -- Lukas > > > On 26.7.2010 18:21, Dave Fugate wrote: > > Hi Lukas, the error message below is because you don?t have the version of > Silverlight installed which was used to build IronPython 2.6.1. For this > particular release, I believe it was something like > ?%ProgramFiles%\Microsoft Silverlight\3.0.40624.0?. You can find out for > sure by examining the ?? element in > Src\IronPython\IronPython.csproj. Any ways, there are two workarounds: > > Replace all instances of ?3.0.40624.0? throughout all C# project files with > the version of Silverlight you have installed locally > > Copy and rename the version of Silverlight you have installed to whatever > is expected by the C# project files > > > > Hope that helps, > > > > Dave > > > > *From:* users-bounces at lists.ironpython.com [ > mailto:users-bounces at lists.ironpython.com] > *On Behalf Of *Lukas Cenovsky > *Sent:* Friday, July 23, 2010 12:37 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] Building IronPython from sources > > > > Hi all, > I have one wish for the next release of IronPython 2.6.2 (hope it is not > too late...) - please make sure it is possible to build IronPython binaries > from sources. I have downloaded IronPython-2.6.1-Src-Net20SP1.zipand I there is no way for me to build Silverlight binaries from it... > > I have opened the solution in VS 2010, solution file was converted to the > new version, I selected 'Silverlight Debug' as a solution configuration and > I received meny errors as below when building Microsoft.Scripting.dll: > > Error 11 The type 'System.SerializableAttribute' exists in both > 'c:\IronPython-2.6.1\Bin\Silverlight Debug\Microsoft.Scripting.Core.dll' and > 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll' > C:\IronPython-2.6.1\Src\Runtime\Microsoft.Scripting\ArgumentTypeException.cs > 20 6 Microsoft.Scripting > Error 12 The type or namespace name 'Serializable' could not be found > (are you missing a using directive or an assembly reference?) > C:\IronPython-2.6.1\Src\Runtime\Microsoft.Scripting\ArgumentTypeException.cs > 20 6 Microsoft.Scripting > > My goal was to build debug-able Microsoft.Scripting.Silverlight.dll because > I'm receiving AddReference error which I'd like to inspect. > > -- > -- Lukas > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing listUsers at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > -- http://www.ironpythoninaction.com/ > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.meyer at gmail.com Mon Aug 9 06:43:58 2010 From: tony.meyer at gmail.com (Tony Meyer) Date: Mon, 9 Aug 2010 16:43:58 +1200 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy wrote: > if [Iron*] die, doesn't that mean MS made the right choice after all? I don't think that's true. .NET isn't just another platform - it's Microsoft's own platform. Some thoughts: Like it or not, and whether it *should* be the case or not, in many organisations (or even teams) if a technology is from Microsoft then it's automatically approved, or at least much easier to approve. The barrier to using Iron* is much lower because they are Microsoft products - this is even more the case with Visual Studio integration. Although Iron* are open-source (which is great, obviously), they aren't typical open-source communities, because of the (somewhat understandable) restriction about accepting code, and the leadership all (AFAIK) being within Microsoft. Microsoft have created this environment (which has worked fairly well so far), and it's not clear how easily that can transition to something that's lead by someone (or ones) outside of Microsoft. Leadership (or at least involvement) within Microsoft opens opportunities for Iron* development to influence .NET. I'm not overly familiar with the details, but I gather than the DLR approach is significantly superior to the IPy 1 CLR approach, and that some of the new dynamic features of C# have benefited from this. It's hard to see how a community IronPython could have developed the DLR, and it seems unlikely that Microsoft would make changes to the CLR to assist it. (Does the latest Microsoft Javascript engine use the DLR (Managed JScript?) - if so, then there's hope, I guess). Projects often need 'angels', especially in the early stages (and I would argue that Iron* are still in early stages). Working on a project of this size takes a lot of resources, and having corporate sponsors makes that a lot easier. Would Python have succeeded if CWI, CNRI, and BeOpen hadn't supported Guido (and others)'s work in the early days? These days the PSF takes this role, but projects need time to build to that sort of size. [Iron]Python (I don't really know much about [Iron]Ruby) is a great language for beginners (students, kids, hobbyists, etc). The Iron variants provide a very smooth path into other .NET development (e.g. C# - which I would say is not at all a great beginner's language). You could argue that Visual Basic provides this functionality as well - I personally find Python much superior to Visual Basic, and since nearly all other BASIC variants are dead now, it doesn't provide an easy road into the .NET world (you have to start there with an unfamiliar language). This last point is the most relevant to me. Over the last few years, NorthTec have switched to using CPython as the first-course programming language, and IronPython as the second-course language. The students *need* to end up with some .NET and Visual Studio experience, because realistically that's what they are most likely to come across in the real world. Many of the students are not capable of starting with C#. If IronPython wasn't a Microsoft project, it would have been considerably more difficult to adopt it - that would likely have meant using Visual Basic (possibly in both courses, because these students struggle learning two languages in their first year). Although this is my unique case, I suspect that there are similar ones, where being a Microsoft product is a deciding factor in whether Iron* can be used (which then impacts the adoption of the language, and therefore whether the language survives). > I think Microsoft is throwing their weight behind JavaScript as their > dynamic language of choice, and I can't really blame them. My hope is that Microsoft realises they have enough weight to throw it in more than once place. (My longer hope, which I know is quite unlikely, is that Windows 8 or 9 includes some version of Iron* out of the box, like OS X includes Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files rather than .exes would significantly help Iron* adoption IMO (and this is something completely impossible for a non-Microsoft Iron*). I know some people must like PowerShell and similar things could be done with it, but it's not the same as having a language with the power and cross-platform nature of Python). Cheers, Tony From mlkjih at gmail.com Mon Aug 9 18:10:19 2010 From: mlkjih at gmail.com (mlkjih mlkjih) Date: Mon, 9 Aug 2010 20:10:19 +0400 Subject: [IronPython] Similarity with builtin types Message-ID: http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types What's the point? Is there any plans to support extension methods, something like IronRuby's *using_clr_extensions? With immutable types it cannot be done, am I right? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Mon Aug 9 19:12:53 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Mon, 9 Aug 2010 10:12:53 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75203. ADDED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Wpf $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Wpf/IronPython.Wpf.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Wpf/wpf.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CollectionUtils.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CompilerServices $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugContext.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugContext.GeneratorLoopProc.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugFrame.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebuggableLambdaBuilder.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugGenerator.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugInfoRewriter.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugMode.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugSourceFile.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugSourceSpan.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugThread.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DelegateHelpers.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/ForceToGeneratorLoopException.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/FunctionInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/IDebugCallback.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/InvokeTargets.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/LambdaWalker.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/Microsoft.Scripting.Debugging.Generated.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeOps.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeVariablesSupport $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/ScopedRuntimeVariables.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/ThreadLocal.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TraceEventKind.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/VariableInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CompilerServices/DebugLambdaInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CompilerServices/IDebugCompilerSupport.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl/DebugRuntimeVariables.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl/DefaultDebugThread.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl/DefaultDebugThreadFactory.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeVariablesSupport/IDebugRuntimeVariables.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeVariablesSupport/IDebugThreadFactory.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline/ITraceCallback.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline/ITracePipeline.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline/TracePipeline.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/SimpleSrcLocation.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/SingleDict.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/IReferenceable.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/MemberReferences.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/AsyncAccess.cs DELETED SOURCES $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Debugging $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/IVariableDefContainer.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/AsyncAbort.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Wpf/IronPython.Wpf.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Wpf/wpf.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/IronPython.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Hosting/Python.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Hosting/PythonService.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Modules/sys.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ClrModule.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonBinder.cs $/IronPython/IronPython_Main/Languages/IronPython/Scripts/run_interactive.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_cliclass.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_dllsite.py $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/GlobalSuppressions.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CollectionUtils.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugContext.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugContext.GeneratorLoopProc.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugFrame.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebuggableLambdaBuilder.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugGenerator.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugInfoRewriter.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugMode.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugSourceFile.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugSourceSpan.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DebugThread.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DelegateHelpers.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/ForceToGeneratorLoopException.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/FunctionInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/IDebugCallback.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/InvokeTargets.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/LambdaWalker.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/Microsoft.Scripting.Debugging.Generated.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeOps.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/ScopedRuntimeVariables.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/ThreadLocal.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TraceEventKind.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/VariableInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CompilerServices/DebugLambdaInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/CompilerServices/IDebugCompilerSupport.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl/DebugRuntimeVariables.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl/DefaultDebugThread.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/DefaultRuntimeVariablesImpl/DefaultDebugThreadFactory.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeVariablesSupport/IDebugRuntimeVariables.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/RuntimeVariablesSupport/IDebugThreadFactory.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline/ITraceCallback.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline/ITracePipeline.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Debugging/TracePipeline/TracePipeline.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Runtime/DynamicXamlReader.cs $/IronPython/IronPython_Main/Solutions/IronPython.sln $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Navigation/EditFilter.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Project/PythonStarter.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore/PythonRuntimeHost.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore/Intellisense/PythonAnalyzer.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore/Repl/RemotePythonEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/IAnalysisValue.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/IAnalysisVariable.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/ModuleAnalysis.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/ProjectEntry.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/ProjectState.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/SimpleSrcLocation.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/AnalysisUnit.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/DDG.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/ExpressionEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/InterpreterScope.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/OverviewWalker.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/SingleDict.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/TypeUnion.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Interpreter/VariableDef.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/BuiltinClassInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/BuiltinEventInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/BuiltinInstanceInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/BuiltinModule.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/BuiltinNamespace.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/ClassInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/ConstantInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/DependencyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/FunctionInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/InstanceInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/IReferenceable.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/MemberReferences.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/MethodInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/ModuleInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/Namespace.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/PyAnalysis/Values/ReflectedNamespace.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio/Navigation/HierarchyListener.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio/Repl/VsReplWindow.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/DlrClassifier.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Intellisense/XamlAnalysis.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/AsyncAccess.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/ExecutionQueue.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/RemoteProxy.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/RemoteScriptFactory.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/DlrEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/ReplEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/ReplWindow.cs CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1958770 Date: 8/5/2010 11:25:21 AM Fixes the MSI so that IronPython Tools works again ? the MSI now installs both IronPython Tools and IronStudio separately. Updates go package to have a ?toolsbin option which uses the IronPython Tools ipy/DLR binaries for producing the MSI. This lets us have a simple batch file which generates a testable MSI (which is added into the IronStudio directory as IpyMsi). Moves installer location code into IronPythonCore so the analysis engine can use it to find the DLLs directory (if it exists). Move analysis of XAML files onto the analysis thread because it can trigger analysis of Python code. Fix completions showing up when typing space (e.g. ?x = ?) Add command dispatcher support to RemoteScriptFactory and wire it up to IronPython?s command dispatcher. Also removes dependency on IronPython.dll. Improve goto definitions distinction between assignments and definitions. Only show values for local variables. For other variables include all references to the type. Fix goto def / find all refs on a method in a class by searching backwards. Improve re-analysis between XAML and .py files. Add support for wpf module ? retarget where we look for LoadComponent and support searching the DLLs dir in general. Always evaluate RHS of augmented assign even if LHS value is not known. Add reference tracking back onto user defined objects, and track references when a value is looked up by name. Now ?x = SomeClass? shows up as a reference. Improve memory usage of variable defs by optimizing for the single type assigned case. Improve type tracking of variable defs by storing the dependency of a user defined into in the user defined?s declaring module. Also we no longer propagate stale values. Track references to built-ins. Propagate types when calling a delegate type and passing in a function. Display None value as None and not NoneType. Reduce memory usage required to store references by not using SourceSpan. Fix order of attribute lookup on an instance ? look in class and then instance. Fix result type of is and is not operators to always be bool. Add support for analyzing XAML files in IronStudio. Fix content menu, paste, and char type commands in REPL. Fix bug in REPL where we weren?t noticing deletes because the overlap was empty. Report line number information in XAML analysis for named elements. Simplify DLR evaluator removing dead and otherwise useless code. Fix REPL bug w/ clear screen where you could no longer type afterwards. (Shelveset: ToolsGotoDefMsiAndBugs;REDMOND\dinov | SNAP CheckinId: 11238) -------------------------------------------------------------------------------- Changeset Id: 1956311 Date: 8/4/2010 12:48:54 PM Moves IronPython?s LoadComponent support to a new (optional) wpf module. This enables it to depend upon WPF which fixes a bug where data binding isn?t working when we use the default XAML schema context. The DLL is added to the DLLs directory and everything including the MSI is updated to include it. Test_dllsite needed to be updated to deal w/ the presence of this directory. Also re-orders the parameters to that the target object comes first in LoadComponent. To keep the balance of DLLs the same this gets rid of Microsoft.Scripting.Debugging and folds that into Microsoft.Dynamic.dll (this was planned anyway after Tomas added the metadata DLL). The assembly load order has changed and this broke test_interactive ? including the extensions causes us to do a LoadFile when we want a normal load. (Shelveset: wpfdllsfinal;REDMOND\dinov | SNAP CheckinId: 11236) -------------------------------------------------------------------------------- Changeset Id: 1953691 Date: 8/3/2010 11:50:02 AM Updates the Python class: Python: Adds GetModuleFilenames so we can remove an IronStudio dependency on IronPython PythonService: Adds GetModuleFilenames implementation and DispatchCommand/GetSetCommandDispatcher/GetLocalCommandDispatcher for WPF repl support (this is basically existing functionality exposed to hosts) Changed CommandDispatcher type to Action so it doesn?t need to be a Python specific type (which will fit better into IronStudio). (Shelveset: ServiceUpdates;REDMOND\dinov | SNAP CheckinId: 11232) From dinov at microsoft.com Mon Aug 9 19:25:20 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 17:25:20 +0000 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: As far as extension methods go - and just extension methods - we may at some point in time support them. We won't ever support Ruby's mutation of everything under the sun including built-in types simply because that's not something CPython supports. The tricky part w/ the extension methods is doing it in a way which is per-module instead of at a global scope. In Ruby so much code mutates object that it's not really a big deal to add in some more mutation of types across the system. But w/ Python these sort of changes have always been more closely scoped - for example look at from __future__ import ... which effects only the current module. Another example is our own "import clr" which makes .NET attributes available on the built-in types. I suspect what we'll end up doing is something like: clr.LoadClrExtensions(namespace) So it'd end up looking like: import System Import clr clr.AddReference(System.Linq) I do want to do something to continue to push LINQ forward for 2.7 and maybe this will be it if I can get it in... Tomas added the metadata reader which we can use to efficiently get the extension methods and I think I might have an idea on how to efficiently share the extension methods across modules. So I guess the question now would be does that look like a reasonable way to load extension methods? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 9:10 AM To: users at lists.ironpython.com Subject: [IronPython] Similarity with builtin types http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types What's the point? Is there any plans to support extension methods, something like IronRuby's using_clr_extensions? With immutable types it cannot be done, am I right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Mon Aug 9 19:29:14 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 9 Aug 2010 11:29:14 -0600 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> References: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> Message-ID: On Mon, Aug 9, 2010 at 11:12 AM, wrote: > Fixes the MSI so that IronPython Tools works again ? the MSI now installs both IronPython Tools and IronStudio separately. Err .. what the heck is IronStudio? Just a version of the isolated shell with IronPython tools already installed, or something more? - Jeff From jdhardy at gmail.com Mon Aug 9 19:37:38 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 9 Aug 2010 11:37:38 -0600 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: On Mon, Aug 9, 2010 at 11:25 AM, Dino Viehland wrote: > clr.LoadClrExtensions(namespace) I'd like to paint the bikeshed 'clr.ImportExtensions()', if possible, and have it take either a namespace or a static class - i.e. System.Linq or System.Linq.Enumerable. import clr, System clr.ImportExtensions(System.Linq) Looks fine to me. For a shorter syntax, I would prefer from System.Linq.Enumerable import * and have it pull in any extension methods in that class. My only concern is that it's a little too magical, and doesn't match the usual behaviour of an import statement. - Jeff From dfugate at microsoft.com Mon Aug 9 19:39:35 2010 From: dfugate at microsoft.com (Dave Fugate) Date: Mon, 9 Aug 2010 17:39:35 +0000 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: References: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> Message-ID: <299545F35D442642800736DBA0C3AA2803408BDA@TK5EX14MBXC201.redmond.corp.microsoft.com> It's nothing new, and probably needs a less confusing name;) This is just what we refer to the generic IronPython Tools bits as. E.g., IronPython Tools is to IronStudio as IronPython is to DLR. My best, Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Monday, August 09, 2010 10:29 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 CodePlex Source Update On Mon, Aug 9, 2010 at 11:12 AM, wrote: > Fixes the MSI so that IronPython Tools works again - the MSI now installs both IronPython Tools and IronStudio separately. Err .. what the heck is IronStudio? Just a version of the isolated shell with IronPython tools already installed, or something more? - Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Mon Aug 9 19:46:25 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 17:46:25 +0000 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: Jeff wrote: > On Mon, Aug 9, 2010 at 11:25 AM, Dino Viehland wrote: > > clr.LoadClrExtensions(namespace) > > I'd like to paint the bikeshed 'clr.ImportExtensions()', if possible, > and have it take either a namespace or a static class - i.e. > System.Linq or System.Linq.Enumerable. > > import clr, System > clr.ImportExtensions(System.Linq) > > Looks fine to me. > > For a shorter syntax, I would prefer > > from System.Linq.Enumerable import * > > and have it pull in any extension methods in that class. My only > concern is that it's a little too magical, and doesn't match the usual > behaviour of an import statement. +1 on allowing the types, that's a good idea. My biggest concern w/ using import semantics for this is Brett's goal (which I am +100 on) to move to a Python implementation of import. Once that happens it'll be either very difficult or impossible to make this syntax work. Even import clr will need to change to be something we recognize at compile time like from __future__. So I'm inclined not to do that - plus it may be boarding too close on embracing and extending :) From dinov at microsoft.com Mon Aug 9 19:55:02 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 17:55:02 +0000 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: <299545F35D442642800736DBA0C3AA2803408BDA@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> <299545F35D442642800736DBA0C3AA2803408BDA@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-ID: Just to be a little more concrete "IronStudio" consists of: MPFProj - this is mostly just taken as-is (there's a few bug fixes) Subclasses of MPFProj which add more functionality and customize it in various ways A VS REPL (MEF) component that can support multiple languages Managed code to implement and support the "Object Browser" feature of VS Helper classes for things like setting up an analysis queue, talking to remote DLR based scripting languages Helper classes to easier connect DLR based APIs to VS based APIs As Dave says "IronStudio" isn't necessarily a great name but it's the name that was used when a lot this code was originally written (2-3 years ago). > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dave Fugate > Sent: Monday, August 09, 2010 10:40 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.6 CodePlex Source Update > > It's nothing new, and probably needs a less confusing name;) This is just > what we refer to the generic IronPython Tools bits as. E.g., IronPython Tools > is to IronStudio as IronPython is to DLR. > > My best, > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Monday, August 09, 2010 10:29 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.6 CodePlex Source Update > > On Mon, Aug 9, 2010 at 11:12 AM, wrote: > > Fixes the MSI so that IronPython Tools works again - the MSI now installs > both IronPython Tools and IronStudio separately. > > Err .. what the heck is IronStudio? Just a version of the isolated shell with > IronPython tools already installed, or something more? > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From mlkjih at gmail.com Mon Aug 9 19:58:11 2010 From: mlkjih at gmail.com (mlkjih mlkjih) Date: Mon, 9 Aug 2010 21:58:11 +0400 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: >We won?t ever support Ruby?s mutation of everything under the sun including built-in types simply because that?s not something CPython supports. With clr.LoadClrExtensions using C# extension methods we can extend builtin types, public string DoSomething(this string str) ... so why not just allow use ironpython for this? String.DoSomething = ... 2010/8/9 Dino Viehland > As far as extension methods go ? and just extension methods ? we may at > some point in time support them. We won?t ever support Ruby?s mutation of > everything under the sun including built-in types simply because that?s not > something CPython supports. > > > > The tricky part w/ the extension methods is doing it in a way which is > per-module instead of at a global scope. In Ruby so much code mutates > object that it?s not really a big deal to add in some more mutation of types > across the system. But w/ Python these sort of changes have always been > more closely scoped ? for example look at from __future__ import ? which > effects only the current module. Another example is our own ?import clr? > which makes .NET attributes available on the built-in types. > > > > I suspect what we?ll end up doing is something like: > > > > clr.LoadClrExtensions(namespace) > > > > So it?d end up looking like: > > > > import System > > Import clr > > clr.AddReference(System.Linq) > > > > > > I do want to do something to continue to push LINQ forward for 2.7 and > maybe this will be it if I can get it in? Tomas added the metadata reader > which we can use to efficiently get the extension methods and I think I > might have an idea on how to efficiently share the extension methods across > modules. > > > > So I guess the question now would be does that look like a reasonable way > to load extension methods? > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mlkjih mlkjih > *Sent:* Monday, August 09, 2010 9:10 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Similarity with builtin types > > > > > http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types > What's the point? Is there any plans to support extension methods, > something like IronRuby's *using_clr_extensions? With immutable types it > cannot be done, am I right?* > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Aug 9 20:20:20 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 18:20:20 +0000 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: Because you can't do that in CPython. If we enabled that we'd certainly instantly start failing a number of tests and we might subtly break compatibility of libraries that might try do assign, catch a TypeError/AttributeError, and then do something else (even if that sounds like a terrible idea). I also think it's nicer to be explicit here that you're doing something which requires IronPython by forcing the "import clr" so that it's clearer this code won't work on CPython. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 10:58 AM To: Discussion of IronPython Subject: Re: [IronPython] Similarity with builtin types >We won't ever support Ruby's mutation of everything under the sun including built-in types simply because that's not something CPython supports. With clr.LoadClrExtensions using C# extension methods we can extend builtin types, public string DoSomething(this string str) ... so why not just allow use ironpython for this? String.DoSomething = ... 2010/8/9 Dino Viehland > As far as extension methods go - and just extension methods - we may at some point in time support them. We won't ever support Ruby's mutation of everything under the sun including built-in types simply because that's not something CPython supports. The tricky part w/ the extension methods is doing it in a way which is per-module instead of at a global scope. In Ruby so much code mutates object that it's not really a big deal to add in some more mutation of types across the system. But w/ Python these sort of changes have always been more closely scoped - for example look at from __future__ import ... which effects only the current module. Another example is our own "import clr" which makes .NET attributes available on the built-in types. I suspect what we'll end up doing is something like: clr.LoadClrExtensions(namespace) So it'd end up looking like: import System Import clr clr.AddReference(System.Linq) I do want to do something to continue to push LINQ forward for 2.7 and maybe this will be it if I can get it in... Tomas added the metadata reader which we can use to efficiently get the extension methods and I think I might have an idea on how to efficiently share the extension methods across modules. So I guess the question now would be does that look like a reasonable way to load extension methods? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 9:10 AM To: users at lists.ironpython.com Subject: [IronPython] Similarity with builtin types http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types What's the point? Is there any plans to support extension methods, something like IronRuby's using_clr_extensions? With immutable types it cannot be done, am I right? _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlkjih at gmail.com Mon Aug 9 20:30:42 2010 From: mlkjih at gmail.com (mlkjih mlkjih) Date: Mon, 9 Aug 2010 22:30:42 +0400 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: What about some sort of switcher to enable ironpython specific features? import allow_builtin_type_extensions 2010/8/9 Dino Viehland > Because you can?t do that in CPython. If we enabled that we?d certainly > instantly start failing a number of tests and we might subtly break > compatibility of libraries that might try do assign, catch a > TypeError/AttributeError, and then do something else (even if that sounds > like a terrible idea). > > > > I also think it?s nicer to be explicit here that you?re doing something > which requires IronPython by forcing the ?import clr? so that it?s clearer > this code won?t work on CPython. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mlkjih mlkjih > *Sent:* Monday, August 09, 2010 10:58 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Similarity with builtin types > > > > >We won?t ever support Ruby?s mutation of everything under the sun > including built-in types simply because that?s not something CPython > supports. > > With clr.LoadClrExtensions using C# extension methods we can extend builtin > types, > public string DoSomething(this string str) ... > so why not just allow use ironpython for this? > String.DoSomething = ... > > 2010/8/9 Dino Viehland > > As far as extension methods go ? and just extension methods ? we may at > some point in time support them. We won?t ever support Ruby?s mutation of > everything under the sun including built-in types simply because that?s not > something CPython supports. > > > > The tricky part w/ the extension methods is doing it in a way which is > per-module instead of at a global scope. In Ruby so much code mutates > object that it?s not really a big deal to add in some more mutation of types > across the system. But w/ Python these sort of changes have always been > more closely scoped ? for example look at from __future__ import ? which > effects only the current module. Another example is our own ?import clr? > which makes .NET attributes available on the built-in types. > > > > I suspect what we?ll end up doing is something like: > > > > clr.LoadClrExtensions(namespace) > > > > So it?d end up looking like: > > > > import System > > Import clr > > clr.AddReference(System.Linq) > > > > > > I do want to do something to continue to push LINQ forward for 2.7 and > maybe this will be it if I can get it in? Tomas added the metadata reader > which we can use to efficiently get the extension methods and I think I > might have an idea on how to efficiently share the extension methods across > modules. > > > > So I guess the question now would be does that look like a reasonable way > to load extension methods? > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mlkjih mlkjih > *Sent:* Monday, August 09, 2010 9:10 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Similarity with builtin types > > > > > http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types > What's the point? Is there any plans to support extension methods, > something like IronRuby's *using_clr_extensions? With immutable types it > cannot be done, am I right?* > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Aug 9 20:34:21 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 18:34:21 +0000 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: That probably won't happen - I think we may have tried that with Java at one point in time :) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 11:31 AM To: Discussion of IronPython Subject: Re: [IronPython] Similarity with builtin types What about some sort of switcher to enable ironpython specific features? import allow_builtin_type_extensions 2010/8/9 Dino Viehland > Because you can't do that in CPython. If we enabled that we'd certainly instantly start failing a number of tests and we might subtly break compatibility of libraries that might try do assign, catch a TypeError/AttributeError, and then do something else (even if that sounds like a terrible idea). I also think it's nicer to be explicit here that you're doing something which requires IronPython by forcing the "import clr" so that it's clearer this code won't work on CPython. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 10:58 AM To: Discussion of IronPython Subject: Re: [IronPython] Similarity with builtin types >We won't ever support Ruby's mutation of everything under the sun including built-in types simply because that's not something CPython supports. With clr.LoadClrExtensions using C# extension methods we can extend builtin types, public string DoSomething(this string str) ... so why not just allow use ironpython for this? String.DoSomething = ... 2010/8/9 Dino Viehland > As far as extension methods go - and just extension methods - we may at some point in time support them. We won't ever support Ruby's mutation of everything under the sun including built-in types simply because that's not something CPython supports. The tricky part w/ the extension methods is doing it in a way which is per-module instead of at a global scope. In Ruby so much code mutates object that it's not really a big deal to add in some more mutation of types across the system. But w/ Python these sort of changes have always been more closely scoped - for example look at from __future__ import ... which effects only the current module. Another example is our own "import clr" which makes .NET attributes available on the built-in types. I suspect what we'll end up doing is something like: clr.LoadClrExtensions(namespace) So it'd end up looking like: import System Import clr clr.AddReference(System.Linq) I do want to do something to continue to push LINQ forward for 2.7 and maybe this will be it if I can get it in... Tomas added the metadata reader which we can use to efficiently get the extension methods and I think I might have an idea on how to efficiently share the extension methods across modules. So I guess the question now would be does that look like a reasonable way to load extension methods? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 9:10 AM To: users at lists.ironpython.com Subject: [IronPython] Similarity with builtin types http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types What's the point? Is there any plans to support extension methods, something like IronRuby's using_clr_extensions? With immutable types it cannot be done, am I right? _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Mon Aug 9 21:07:10 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 9 Aug 2010 13:07:10 -0600 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: References: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> <299545F35D442642800736DBA0C3AA2803408BDA@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-ID: Thanks for the explanation, guys. On Mon, Aug 9, 2010 at 11:55 AM, Dino Viehland wrote: > As Dave says "IronStudio" isn't necessarily a great name but it's the name > that was used when a lot this code was originally written (2-3 years ago). Wow, I didn't realize it had been baking for that long. - Jeff From jdhardy at gmail.com Mon Aug 9 21:13:59 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 9 Aug 2010 13:13:59 -0600 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: On Mon, Aug 9, 2010 at 11:46 AM, Dino Viehland wrote: > My biggest concern w/ using import semantics for this is Brett's goal > (which I am +100 on) to move to a Python implementation of import. > Once that happens it'll be either very difficult or impossible to > make this syntax work. ?Even import clr will need to change to be > something we recognize at compile time like from __future__. So I'm > inclined not to do that - plus it may be boarding too close on > embracing and extending :) Oh right, I forgot about that project - presumably all the Pythons would share their import code? That'll go nicely with a split-out standard library. In that case, making the clr module the entry point for all of IronPython's magic is the best idea. For 3.2, maybe it should change to __clr__ so that it's clear that it's magic - things are going to break anyway, and it would be an easy 2to3 fixer. Or see if Guido will let you borrow the time machine :). - Jeff From dinov at microsoft.com Mon Aug 9 21:41:31 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 19:41:31 +0000 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: References: <9a670214-854a-47f3-bca1-4c46339518e2@tk5-exsmh-c101.redmond.corp.microsoft.com> <299545F35D442642800736DBA0C3AA2803408BDA@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-ID: Jeff wrote: > Thanks for the explanation, guys. > > On Mon, Aug 9, 2010 at 11:55 AM, Dino Viehland wrote: > > As Dave says "IronStudio" isn't necessarily a great name but it's the name > > that was used when a lot this code was originally written (2-3 years ago). > > Wow, I didn't realize it had been baking for that long. It hadn't quite been baking for that long - really IpyTools is the culmination of about 5 separate attempts of providing tooling for IronPython. It directly borrows code from at least 2 of those attempts and probably some ideas from other attempts. So it was more parbaking as we stopped and started and rethought what we were doing :) From kurt at kurtrichardson.com Mon Aug 9 22:28:25 2010 From: kurt at kurtrichardson.com (Kurt A Richardson) Date: Mon, 09 Aug 2010 13:28:25 -0700 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 Message-ID: <4C6064E9.9050206@kurtrichardson.com> Hi forum I've been trying to install IronPython 2.7A1 from codeplex on my Windows 7 box running VS 2010 Pro. However as soon as I install IP and open VS 2010, VS2010 hangs, and I can't even open a VB code file. Whenever I attempt to open a file VS 2010 gives me the following error: Internal error occurred. Additional information: "." As soon as I uninstall IronPython 2.7A1, VS2010 starts working properly again. I have tried uninstalling/reinstalling VS 2010 several times, but I still can't get it to load-up properly with IronPython 2.7A1 installed. Has anyone else seen this behavior? Any ideas on how I might correct it. I was hoping to have a IronPython/ASP.NET website ready for a simple demo this Thursday, but am getting nowhere fast. I have written a number of IronPython libraries to control a XBee transceiver as part of a Smart Home application I'm developing, and want to show that I can switch a fan on/off from a web app remotely. Many thanks for any tips and guidance. Kurt From jdhardy at gmail.com Mon Aug 9 22:47:42 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 9 Aug 2010 14:47:42 -0600 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C6064E9.9050206@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> Message-ID: You should be able to install it without the Visual Studio support; doesn't help of that's what you were hoping to show off, but at least it will work. Just set the 'Tools for Visual Studio' option to 'Do not install'. - Jeff On Mon, Aug 9, 2010 at 2:28 PM, Kurt A Richardson wrote: > Hi forum > > I've been trying to install IronPython 2.7A1 from codeplex on my Windows 7 > box running VS 2010 Pro. ?However as soon as I install IP and open VS 2010, > VS2010 hangs, and I can't even open a VB code file. ?Whenever I attempt to > open a file VS 2010 gives me the following error: > > Internal error occurred. Additional information: "." > > As soon as I uninstall IronPython 2.7A1, VS2010 starts working properly > again. > > I have tried uninstalling/reinstalling VS 2010 several times, but I still > can't get it to load-up properly with IronPython 2.7A1 installed. > > Has anyone else seen this behavior? ?Any ideas on how I might correct it. ?I > was hoping to have a IronPython/ASP.NET website ready for a simple demo this > Thursday, but am getting nowhere fast. ?I have written a number of > IronPython libraries to control a XBee transceiver as part of a Smart Home > application I'm developing, and want to show that I can switch a fan on/off > from a web app remotely. > > Many thanks for any tips and guidance. > > Kurt > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at microsoft.com Mon Aug 9 22:54:03 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 20:54:03 +0000 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C6064E9.9050206@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> Message-ID: I haven't seen it - do you have any other extensions installed in VS? Any chance you can download windbg (http://www.windbg.org/) and attach and report back any CLR exceptions you're seeing? There will certainly be a lot of them but you can start windbg using: "%ProgramFiles%\Debugging Tools for Windows (x86)\windbg.exe" "%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" Then once windbg starts type into the prompt at the bottom: sxe ld clr.dll g When it stops type: .loadby sos clr sxe -c "!pe; !ClrStack; g" clr sxe -c "kb30; g" eh .symfix .reload g And then send the contents of windbg's output back? I can take a look at it and see if anything obvious jumps out. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Kurt A Richardson > Sent: Monday, August 09, 2010 1:28 PM > To: users at lists.ironpython.com > Subject: [IronPython] Trouble with IP 7.0 and VS 2010 > > Hi forum > > I've been trying to install IronPython 2.7A1 from codeplex on my Windows > 7 box running VS 2010 Pro. However as soon as I install IP and open VS > 2010, VS2010 hangs, and I can't even open a VB code file. Whenever I > attempt to open a file VS 2010 gives me the following error: > > Internal error occurred. Additional information: "." > > As soon as I uninstall IronPython 2.7A1, VS2010 starts working properly > again. > > I have tried uninstalling/reinstalling VS 2010 several times, but I > still can't get it to load-up properly with IronPython 2.7A1 installed. > > Has anyone else seen this behavior? Any ideas on how I might correct > it. I was hoping to have a IronPython/ASP.NET website ready for a > simple demo this Thursday, but am getting nowhere fast. I have written > a number of IronPython libraries to control a XBee transceiver as part > of a Smart Home application I'm developing, and want to show that I can > switch a fan on/off from a web app remotely. > > Many thanks for any tips and guidance. > > Kurt > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Mon Aug 9 23:17:15 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 9 Aug 2010 21:17:15 +0000 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: Jeff wrote: > On Mon, Aug 9, 2010 at 11:25 AM, Dino Viehland wrote: > > clr.LoadClrExtensions(namespace) > > I'd like to paint the bikeshed 'clr.ImportExtensions()', if possible, > and have it take either a namespace or a static class - i.e. > System.Linq or System.Linq.Enumerable. > > import clr, System > clr.ImportExtensions(System.Linq) > > Looks fine to me. > > For a shorter syntax, I would prefer > > from System.Linq.Enumerable import * > > and have it pull in any extension methods in that class. My only > concern is that it's a little too magical, and doesn't match the usual > behaviour of an import statement. Ok, +1 on ImportExtensions for the name form me. There's also 1 limitation which occurs to me: We will only allow extension methods which don't clash on the base class to appear. So for example if you define: class MyClass : IEnumerable { public void Where() { } } Then the extension Where won't be available. Unfortunately I think that's the only way we can really do this efficiently. Of course you'll still be able to call System.Linq.Enumerable.Where. Sound reasonable? From jdhardy at gmail.com Mon Aug 9 23:34:25 2010 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 9 Aug 2010 15:34:25 -0600 Subject: [IronPython] Similarity with builtin types In-Reply-To: References: Message-ID: On Mon, Aug 9, 2010 at 3:17 PM, Dino Viehland wrote: > Jeff wrote: > There's also 1 limitation which occurs to me: ?We will only allow extension > methods which don't clash on the base class to appear. ?So for example if you > define: > > class MyClass : IEnumerable { > ? ? ? ?public void Where() { > ? ? ? ?} > } > > Then the extension Where won't be available. ?Unfortunately I think that's the > only way we can really do this efficiently. ?Of course you'll still be able to > call System.Linq.Enumerable.Where. > > Sound reasonable? I think so. There might be a few cases where that could cause some confusion, but those are probably poorly-designed extension methods anyway - generally the in-class version would be preferred to the extension method. - Jeff From hank at prosysplus.com Mon Aug 9 23:34:26 2010 From: hank at prosysplus.com (Hank Fay) Date: Mon, 9 Aug 2010 17:34:26 -0400 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: Hi Tony, I have to agree about the barrier being lower if IPy is Microsoft-supported (as all the Iron* languages were announced to be). I had a discussion in January with a market-leader in another country, and their project manager could accept IronPython, barely. His take was: I want to be able to easily hire programmers for customization and/or sourcecode escrow clause necessity. Customization wasn't really an issue (the program uses hooks for customization), as he could hire his bevy of C# developers to do that, but if he had to maintain sourcecode that would be a different story. Having come from a very productive dynamic language (Visual FoxPro) that MS first said could not be ported to .Net, and then when it obviously was possible (in 2005) made no attempt to do so, I'm having a deja vu experience all over again. I'll try not to be as cynical and sarcastic as last time, but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my tongue to prevent shouting out "Middle Management Uber Alles!" (referencing Jimmy's blog post). And so it goes... Hank On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer wrote: > On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy wrote: > > if [Iron*] die, doesn't that mean MS made the right choice after all? > > I don't think that's true. .NET isn't just another platform - it's > Microsoft's own platform. Some thoughts: > > Like it or not, and whether it *should* be the case or not, in many > organisations (or even teams) if a technology is from Microsoft then > it's automatically approved, or at least much easier to approve. The > barrier to using Iron* is much lower because they are Microsoft > products - this is even more the case with Visual Studio integration. > > Although Iron* are open-source (which is great, obviously), they > aren't typical open-source communities, because of the (somewhat > understandable) restriction about accepting code, and the leadership > all (AFAIK) being within Microsoft. Microsoft have created this > environment (which has worked fairly well so far), and it's not clear > how easily that can transition to something that's lead by someone (or > ones) outside of Microsoft. > > Leadership (or at least involvement) within Microsoft opens > opportunities for Iron* development to influence .NET. I'm not overly > familiar with the details, but I gather than the DLR approach is > significantly superior to the IPy 1 CLR approach, and that some of the > new dynamic features of C# have benefited from this. It's hard to see > how a community IronPython could have developed the DLR, and it seems > unlikely that Microsoft would make changes to the CLR to assist it. > (Does the latest Microsoft Javascript engine use the DLR (Managed > JScript?) - if so, then there's hope, I guess). > > Projects often need 'angels', especially in the early stages (and I > would argue that Iron* are still in early stages). Working on a > project of this size takes a lot of resources, and having corporate > sponsors makes that a lot easier. Would Python have succeeded if CWI, > CNRI, and BeOpen hadn't supported Guido (and others)'s work in the > early days? These days the PSF takes this role, but projects need > time to build to that sort of size. > > [Iron]Python (I don't really know much about [Iron]Ruby) is a great > language for beginners (students, kids, hobbyists, etc). The Iron > variants provide a very smooth path into other .NET development (e.g. > C# - which I would say is not at all a great beginner's language). > You could argue that Visual Basic provides this functionality as well > - I personally find Python much superior to Visual Basic, and since > nearly all other BASIC variants are dead now, it doesn't provide an > easy road into the .NET world (you have to start there with an > unfamiliar language). > > This last point is the most relevant to me. Over the last few years, > NorthTec have switched to using CPython as the first-course > programming language, and IronPython as the second-course language. > The students *need* to end up with some .NET and Visual Studio > experience, because realistically that's what they are most likely to > come across in the real world. Many of the students are not capable > of starting with C#. If IronPython wasn't a Microsoft project, it > would have been considerably more difficult to adopt it - that would > likely have meant using Visual Basic (possibly in both courses, > because these students struggle learning two languages in their first > year). Although this is my unique case, I suspect that there are > similar ones, where being a Microsoft product is a deciding factor in > whether Iron* can be used (which then impacts the adoption of the > language, and therefore whether the language survives). > > > I think Microsoft is throwing their weight behind JavaScript as their > > dynamic language of choice, and I can't really blame them. > > My hope is that Microsoft realises they have enough weight to throw it > in more than once place. > > (My longer hope, which I know is quite unlikely, is that Windows 8 or > 9 includes some version of Iron* out of the box, like OS X includes > Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files > rather than .exes would significantly help Iron* adoption IMO (and > this is something completely impossible for a non-Microsoft Iron*). I > know some people must like PowerShell and similar things could be done > with it, but it's not the same as having a language with the power and > cross-platform nature of Python). > > Cheers, > Tony > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at kurtrichardson.com Tue Aug 10 02:32:47 2010 From: kurt at kurtrichardson.com (Kurt A Richardson) Date: Mon, 09 Aug 2010 17:32:47 -0700 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C6064E9.9050206@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> Message-ID: <4C609E2F.4070201@kurtrichardson.com> Many thanks Dinov Below is the windbg output after following your instructions: ___________________________________________________________________ Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** Executable search path is: ModLoad: 00000000`2f400000 00000000`2f48e000 devenv.exe ModLoad: 00000000`770a0000 00000000`7724b000 ntdll.dll ModLoad: 00000000`77280000 00000000`77400000 ntdll32.dll ModLoad: 00000000`74d80000 00000000`74dbf000 C:\Windows\SYSTEM32\wow64.dll ModLoad: 00000000`74d20000 00000000`74d7c000 C:\Windows\SYSTEM32\wow64win.dll ModLoad: 00000000`74d10000 00000000`74d18000 C:\Windows\SYSTEM32\wow64cpu.dll (2f88.36fc): Break instruction exception - code 80000003 (first chance) *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ntdll!CsrSetPriorityClass+0x40: 00000000`77151340 cc int 3 0:000> sxe ld clr.dll 0:000> g (2f88.36fc): WOW64 breakpoint - code 4000001f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll32.dll - ntdll32!LdrVerifyImageMatchesChecksum+0x6ce: 77320995 cc int 3 0:000:x86> .loadby sos clr Unable to find module 'clr' 0:000:x86> sxe -c "!pe; !ClrStack; g" clr 0:000:x86> sxe -c "kb30; g" eh 0:000:x86> .symfix 0:000:x86> .reload Reloading current modules ............................ 0:000:x86> g ModLoad: 00000000`66380000 00000000`669ef000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll ntdll!ZwMapViewOfSection+0xa: 00000000`770effda c3 ret ___________________________________________________________________ Does anything jump out? I forgot to mention previously tat I am using 64-bit Win 7, if that makes any dfference. Kindest regards, Kurt On 8/9/2010 1:28 PM, Kurt A Richardson wrote: > Hi forum > > I've been trying to install IronPython 2.7A1 from codeplex on my > Windows 7 box running VS 2010 Pro. However as soon as I install IP > and open VS 2010, VS2010 hangs, and I can't even open a VB code file. > Whenever I attempt to open a file VS 2010 gives me the following error: > > Internal error occurred. Additional information: "." > > As soon as I uninstall IronPython 2.7A1, VS2010 starts working > properly again. > > I have tried uninstalling/reinstalling VS 2010 several times, but I > still can't get it to load-up properly with IronPython 2.7A1 installed. > > Has anyone else seen this behavior? Any ideas on how I might correct > it. I was hoping to have a IronPython/ASP.NET website ready for a > simple demo this Thursday, but am getting nowhere fast. I have > written a number of IronPython libraries to control a XBee transceiver > as part of a Smart Home application I'm developing, and want to show > that I can switch a fan on/off from a web app remotely. > > Many thanks for any tips and guidance. > > Kurt From kurt at kurtrichardson.com Tue Aug 10 02:37:26 2010 From: kurt at kurtrichardson.com (Kurt A Richardson) Date: Mon, 09 Aug 2010 17:37:26 -0700 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C609E2F.4070201@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> Message-ID: <4C609F46.5090604@kurtrichardson.com> PS I do not have any other extensions installed that I am aware of (nothing listed in the extension manager). On 8/9/2010 5:32 PM, Kurt A Richardson wrote: > Many thanks Dinov > > Below is the windbg output after following your instructions: > > ___________________________________________________________________ > > Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 > Copyright (c) Microsoft Corporation. All rights reserved. > > CommandLine: "C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.exe" > Symbol search path is: *** Invalid *** > **************************************************************************** > > * Symbol loading may be unreliable without a symbol search > path. * > * Use .symfix to have the debugger choose a symbol > path. * > * After setting your symbol path, use .reload to refresh symbol > locations. * > **************************************************************************** > > Executable search path is: > ModLoad: 00000000`2f400000 00000000`2f48e000 devenv.exe > ModLoad: 00000000`770a0000 00000000`7724b000 ntdll.dll > ModLoad: 00000000`77280000 00000000`77400000 ntdll32.dll > ModLoad: 00000000`74d80000 00000000`74dbf000 > C:\Windows\SYSTEM32\wow64.dll > ModLoad: 00000000`74d20000 00000000`74d7c000 > C:\Windows\SYSTEM32\wow64win.dll > ModLoad: 00000000`74d10000 00000000`74d18000 > C:\Windows\SYSTEM32\wow64cpu.dll > (2f88.36fc): Break instruction exception - code 80000003 (first chance) > *** ERROR: Symbol file could not be found. Defaulted to export > symbols for ntdll.dll - > ntdll!CsrSetPriorityClass+0x40: > 00000000`77151340 cc int 3 > 0:000> sxe ld clr.dll > 0:000> g > (2f88.36fc): WOW64 breakpoint - code 4000001f (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > *** ERROR: Symbol file could not be found. Defaulted to export > symbols for ntdll32.dll - > ntdll32!LdrVerifyImageMatchesChecksum+0x6ce: > 77320995 cc int 3 > 0:000:x86> .loadby sos clr > Unable to find module 'clr' > 0:000:x86> sxe -c "!pe; !ClrStack; g" clr > 0:000:x86> sxe -c "kb30; g" eh > 0:000:x86> .symfix > 0:000:x86> .reload > Reloading current modules > ............................ > 0:000:x86> g > ModLoad: 00000000`66380000 00000000`669ef000 > C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll > ntdll!ZwMapViewOfSection+0xa: > 00000000`770effda c3 ret > > ___________________________________________________________________ > > Does anything jump out? I forgot to mention previously tat I am using > 64-bit Win 7, if that makes any dfference. > > Kindest regards, Kurt > > On 8/9/2010 1:28 PM, Kurt A Richardson wrote: >> Hi forum >> >> I've been trying to install IronPython 2.7A1 from codeplex on my >> Windows 7 box running VS 2010 Pro. However as soon as I install IP >> and open VS 2010, VS2010 hangs, and I can't even open a VB code >> file. Whenever I attempt to open a file VS 2010 gives me the >> following error: >> >> Internal error occurred. Additional information: "." >> >> As soon as I uninstall IronPython 2.7A1, VS2010 starts working >> properly again. >> >> I have tried uninstalling/reinstalling VS 2010 several times, but I >> still can't get it to load-up properly with IronPython 2.7A1 installed. >> >> Has anyone else seen this behavior? Any ideas on how I might correct >> it. I was hoping to have a IronPython/ASP.NET website ready for a >> simple demo this Thursday, but am getting nowhere fast. I have >> written a number of IronPython libraries to control a XBee >> transceiver as part of a Smart Home application I'm developing, and >> want to show that I can switch a fan on/off from a web app remotely. >> >> Many thanks for any tips and guidance. >> >> Kurt > From dinov at microsoft.com Tue Aug 10 02:48:21 2010 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 10 Aug 2010 00:48:21 +0000 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C609E2F.4070201@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> Message-ID: Bummer, this is the 64-bit windbg, you'll need to do the same thing w/ the 32-bit windbg (it'll have a whole lot more output than this). The 32-bit vs. 64-bit on the download page is really about what process it'll debug, not where it'll run. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Kurt A Richardson > Sent: Monday, August 09, 2010 5:33 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] Trouble with IP 7.0 and VS 2010 > > Many thanks Dinov > > Below is the windbg output after following your instructions: > > ___________________________________________________________________ > > Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 > Copyright (c) Microsoft Corporation. All rights reserved. > > CommandLine: "C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.exe" > Symbol search path is: *** Invalid *** > *********************************************************************** > ***** > * Symbol loading may be unreliable without a symbol search path. > * > * Use .symfix to have the debugger choose a symbol path. > * > * After setting your symbol path, use .reload to refresh symbol > locations. * > *********************************************************************** > ***** > Executable search path is: > ModLoad: 00000000`2f400000 00000000`2f48e000 devenv.exe > ModLoad: 00000000`770a0000 00000000`7724b000 ntdll.dll > ModLoad: 00000000`77280000 00000000`77400000 ntdll32.dll > ModLoad: 00000000`74d80000 00000000`74dbf000 > C:\Windows\SYSTEM32\wow64.dll > ModLoad: 00000000`74d20000 00000000`74d7c000 > C:\Windows\SYSTEM32\wow64win.dll > ModLoad: 00000000`74d10000 00000000`74d18000 > C:\Windows\SYSTEM32\wow64cpu.dll > (2f88.36fc): Break instruction exception - code 80000003 (first chance) > *** ERROR: Symbol file could not be found. Defaulted to export symbols > for ntdll.dll - > ntdll!CsrSetPriorityClass+0x40: > 00000000`77151340 cc int 3 > 0:000> sxe ld clr.dll > 0:000> g > (2f88.36fc): WOW64 breakpoint - code 4000001f (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > *** ERROR: Symbol file could not be found. Defaulted to export symbols > for ntdll32.dll - > ntdll32!LdrVerifyImageMatchesChecksum+0x6ce: > 77320995 cc int 3 > 0:000:x86> .loadby sos clr > Unable to find module 'clr' > 0:000:x86> sxe -c "!pe; !ClrStack; g" clr > 0:000:x86> sxe -c "kb30; g" eh > 0:000:x86> .symfix > 0:000:x86> .reload > Reloading current modules > ............................ > 0:000:x86> g > ModLoad: 00000000`66380000 00000000`669ef000 > C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll > ntdll!ZwMapViewOfSection+0xa: > 00000000`770effda c3 ret > > ___________________________________________________________________ > > Does anything jump out? I forgot to mention previously tat I am using > 64-bit Win 7, if that makes any dfference. > > Kindest regards, Kurt > > On 8/9/2010 1:28 PM, Kurt A Richardson wrote: > > Hi forum > > > > I've been trying to install IronPython 2.7A1 from codeplex on my > > Windows 7 box running VS 2010 Pro. However as soon as I install IP > > and open VS 2010, VS2010 hangs, and I can't even open a VB code file. > > Whenever I attempt to open a file VS 2010 gives me the following > error: > > > > Internal error occurred. Additional information: "." > > > > As soon as I uninstall IronPython 2.7A1, VS2010 starts working > > properly again. > > > > I have tried uninstalling/reinstalling VS 2010 several times, but I > > still can't get it to load-up properly with IronPython 2.7A1 > installed. > > > > Has anyone else seen this behavior? Any ideas on how I might correct > > it. I was hoping to have a IronPython/ASP.NET website ready for a > > simple demo this Thursday, but am getting nowhere fast. I have > > written a number of IronPython libraries to control a XBee > transceiver > > as part of a Smart Home application I'm developing, and want to show > > that I can switch a fan on/off from a web app remotely. > > > > Many thanks for any tips and guidance. > > > > Kurt > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From yngipy at gmail.com Tue Aug 10 05:45:35 2010 From: yngipy at gmail.com (yngipy hernan) Date: Mon, 9 Aug 2010 22:45:35 -0500 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: I completely agree with IPy being Microsoft-supported lowers the barrier of entry to enterprise use. I have this problem long time back using Python as the company is a Microsoft shop (mostly). But IronPython being Microsoft pretty much is approved already, no question ask. I am hoping to hear that IronPython will be supported by MS in the next 2 to 5 years or longer ( forever :-) ) if possible. -yngipy On Mon, Aug 9, 2010 at 4:34 PM, Hank Fay wrote: > Hi Tony, > > I have to agree about the barrier being lower if IPy is Microsoft-supported > (as all the Iron* languages were announced to be). I had a discussion in > January with a market-leader in another country, and their project manager > could accept IronPython, barely. His take was: I want to be able to easily > hire programmers for customization and/or sourcecode escrow clause > necessity. Customization wasn't really an issue (the program uses hooks for > customization), as he could hire his bevy of C# developers to do that, but > if he had to maintain sourcecode that would be a different story. > > Having come from a very productive dynamic language (Visual FoxPro) that MS > first said could not be ported to .Net, and then when it obviously was > possible (in 2005) made no attempt to do so, I'm having a deja vu experience > all over again. I'll try not to be as cynical and sarcastic as last time, > but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my > tongue to prevent shouting out "Middle Management Uber Alles!" (referencing > Jimmy's blog post). > > And so it goes... > > Hank > > > On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer wrote: > >> On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy wrote: >> > if [Iron*] die, doesn't that mean MS made the right choice after all? >> >> I don't think that's true. .NET isn't just another platform - it's >> Microsoft's own platform. Some thoughts: >> >> Like it or not, and whether it *should* be the case or not, in many >> organisations (or even teams) if a technology is from Microsoft then >> it's automatically approved, or at least much easier to approve. The >> barrier to using Iron* is much lower because they are Microsoft >> products - this is even more the case with Visual Studio integration. >> >> Although Iron* are open-source (which is great, obviously), they >> aren't typical open-source communities, because of the (somewhat >> understandable) restriction about accepting code, and the leadership >> all (AFAIK) being within Microsoft. Microsoft have created this >> environment (which has worked fairly well so far), and it's not clear >> how easily that can transition to something that's lead by someone (or >> ones) outside of Microsoft. >> >> Leadership (or at least involvement) within Microsoft opens >> opportunities for Iron* development to influence .NET. I'm not overly >> familiar with the details, but I gather than the DLR approach is >> significantly superior to the IPy 1 CLR approach, and that some of the >> new dynamic features of C# have benefited from this. It's hard to see >> how a community IronPython could have developed the DLR, and it seems >> unlikely that Microsoft would make changes to the CLR to assist it. >> (Does the latest Microsoft Javascript engine use the DLR (Managed >> JScript?) - if so, then there's hope, I guess). >> >> Projects often need 'angels', especially in the early stages (and I >> would argue that Iron* are still in early stages). Working on a >> project of this size takes a lot of resources, and having corporate >> sponsors makes that a lot easier. Would Python have succeeded if CWI, >> CNRI, and BeOpen hadn't supported Guido (and others)'s work in the >> early days? These days the PSF takes this role, but projects need >> time to build to that sort of size. >> >> [Iron]Python (I don't really know much about [Iron]Ruby) is a great >> language for beginners (students, kids, hobbyists, etc). The Iron >> variants provide a very smooth path into other .NET development (e.g. >> C# - which I would say is not at all a great beginner's language). >> You could argue that Visual Basic provides this functionality as well >> - I personally find Python much superior to Visual Basic, and since >> nearly all other BASIC variants are dead now, it doesn't provide an >> easy road into the .NET world (you have to start there with an >> unfamiliar language). >> >> This last point is the most relevant to me. Over the last few years, >> NorthTec have switched to using CPython as the first-course >> programming language, and IronPython as the second-course language. >> The students *need* to end up with some .NET and Visual Studio >> experience, because realistically that's what they are most likely to >> come across in the real world. Many of the students are not capable >> of starting with C#. If IronPython wasn't a Microsoft project, it >> would have been considerably more difficult to adopt it - that would >> likely have meant using Visual Basic (possibly in both courses, >> because these students struggle learning two languages in their first >> year). Although this is my unique case, I suspect that there are >> similar ones, where being a Microsoft product is a deciding factor in >> whether Iron* can be used (which then impacts the adoption of the >> language, and therefore whether the language survives). >> >> > I think Microsoft is throwing their weight behind JavaScript as their >> > dynamic language of choice, and I can't really blame them. >> >> My hope is that Microsoft realises they have enough weight to throw it >> in more than once place. >> >> (My longer hope, which I know is quite unlikely, is that Windows 8 or >> 9 includes some version of Iron* out of the box, like OS X includes >> Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files >> rather than .exes would significantly help Iron* adoption IMO (and >> this is something completely impossible for a non-Microsoft Iron*). I >> know some people must like PowerShell and similar things could be done >> with it, but it's not the same as having a language with the power and >> cross-platform nature of Python). >> >> Cheers, >> Tony >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhoward42 at gmail.com Tue Aug 10 15:13:03 2010 From: peterhoward42 at gmail.com (Peter Howard) Date: Tue, 10 Aug 2010 14:13:03 +0100 Subject: [IronPython] newbie getting started problem Message-ID: Hi I've been following the getting started examples here: http://blog.jimmy.schementi.com/2010/03/pycon-2010-python-in-browser.html I've hit a newbie ignorance problem as soon as I've tried to go 'off-piste' with this (below): (The debug print statement shows up in the repl console and there are no exceptions - but no gui shows up) (In previous Python/Qt contexts I would have been concerned about my script variables going out of scope at the end of the run and GUI artefacts being garbage collected - but the examples I'm copying from don't seem to need any special treatment to avoid garbage collection?). Any help much appreciated - and by the way - after over 20 years as a professional programmer - this is about the most exciting technology combination I've come across. Pete html entry point: ----------------------- python source referenced as app.py: ---------------------------------------------------- from System.Windows import Application from System.Windows.Controls import Canvas, TextBlock canvas = Canvas() textblock = TextBlock() textblock.FontSize = 24 textblock.Text = 'This Really Works!!' canvas.Children.Add(textblock) Application.Current.RootVisual = canvas print 'got to end' -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustaq2001 at gmail.com Tue Aug 10 15:42:39 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Tue, 10 Aug 2010 19:12:39 +0530 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: Hi, I posted this last week and I did not get a response.Hence posting it again. I have an application that creates a python engine in a new appdomain. If I do not specify a lease period I see that the objects are disconnected when I leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" to keep the object alive forever but it did not work. The "dlr-spec-hosting" document mentions the following in page 93 under "Current Issues" section : "Currently if you do not use a host for 15 min, it dies, and you lose your data. We've added InitializeLifetimeService on objects to cause them to stay alive forever, but we need to think through the design and the host controls here". Currently I renew the object using "ILease". I do not know if this is the right thing to do. Could you please suggest me the right way to deal with this issue. I have provided the code below for your reference. Thanks, Mustaq using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is this supposed to keep the object alive forever. lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one day. code.Execute(scope); // If the above lease is not mentioned then execution fails on this line after being inactive for 5 minutes. Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id ); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From curylod at asme.org Tue Aug 10 15:58:58 2010 From: curylod at asme.org (Dave Curylo) Date: Tue, 10 Aug 2010 09:58:58 -0400 Subject: [IronPython] Using isolated storage from IronPython in the browser Message-ID: I'm attempting to use IsolatedStorage from IronPython running the browser, and I keep running into the following error. Any idea what I'm doing wrong or is this functionality currently unsupported? Best regards, Dave MethodAccessException: Security transparent method System.IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForSite() cannot access Microsoft.Scripting.Actions.Calls.MethodCandidate+Caller.Call(System.Object[], Boolean ByRef) using reflection. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Tue Aug 10 16:09:13 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 10 Aug 2010 16:09:13 +0200 Subject: [IronPython] Using isolated storage from IronPython in the browser In-Reply-To: References: Message-ID: <4C615D89.90400@bakalari.cz> Isn't it this issue? http://lists.ironpython.com/pipermail/users-ironpython.com/2010-March/012376.html -- -- Lukas On 10.8.2010 15:58, Dave Curylo wrote: > I'm attempting to use IsolatedStorage from IronPython running the > browser, and I keep running into the following error. Any idea what > I'm doing wrong or is this functionality currently unsupported? > > Best regards, > Dave > > MethodAccessException: Security transparent method System.IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForSite() cannot access Microsoft.Scripting.Actions.Calls.MethodCandidate+Caller.Call(System.Object[], Boolean ByRef) using reflection. > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > > > > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Tue Aug 10 17:39:00 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 10 Aug 2010 08:39:00 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <88e8cff4-d675-426c-b9c5-b75b4d248b99@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75290. MODIFIED SOURCES $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Intellisense/IntellisenseController.cs From vernondcole at gmail.com Tue Aug 10 18:41:22 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Tue, 10 Aug 2010 10:41:22 -0600 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: <4C587947.3000307@bakalari.cz> References: <4C587947.3000307@bakalari.cz> Message-ID: I am afraid Lukas is very correct. (Thanks, you really saved me a lot of debugging time.) This will be an anti-announcement. I got a version (2.4.1A1) of adodbapi working (sort of) on ADO.NET and splatted up against enough difficulties that I have shelved the effort for the present time. I have committed my efforts to a new branch (named ado.net) on the mercurial source tree at http://sourceforge.net/projects/adodbapi/develop for anyone who would like to take up the effort. It might be worthwhile to continue development on an SQL-server specific version, especially if someone has MONO in mind. Since I intended adodbapi to be as universal as possible, I did not want to go that direction. The problems I found were: 1) Lukas was right -- only one datareader per connection. Messes up cursor usage as per the api. 2) cursor.rowcount becomes useless for SELECTs. 3) Connection timeouts are only supported by adding text to the connection strings -- which breaks JET. 4) The "internal size" for cursor.description[3] cannot be retrieved. 5) fine control of cursor location and isolation level is lost. 6) MS documentation vaguely suggests that using ExecuteReader for a command which returns no dataset is a bad idea, which may mean that there is a problem with a stored procedure which may not return a dataset. 7) MS documentation hints that schema results (which are processed into cursor.description) may be incorrect unless a "keyinfo" flag is passed to ExecuteReader, the use of which will cause several possible side effects to the data retrieval. 8) Use of a datareader implies no recordset, so I have to emulate a recordset within my SQLrows object. 9) ADO.NET still uses a COM interface internally to communicate with ADO data adapters -- so what's the point of not using COM directly in my code and keeping all of the lost features? So the COM implementation of adodbapi v2.4.0 will remain as the official "latest and greatest" for IronPython. Thanks for all the fish... Vernon Cole On Tue, Aug 3, 2010 at 2:17 PM, Lukas Cenovsky wrote: > On 3.8.2010 1:24, Vernon Cole wrote: > > What are the consequences of using ExecuteReader() when there is > nothing to read? If none, i.e. you get an empty set of results, then I > would say to use that all the time, and don't bother to examine your > SQL at all. > > > I think ExecuteReader should work for everything. I use only ExecuteReader > in my private tool (but I do not use stored procedures). > > You will have a bigger problem with ADO.NET than this. According to the > Python dbapi specification, you can have as many cursors per connection as > you want. You can have many cursors in ADO.NET too, but you can have only > one SqlDataReader per connections which makes several cursors per connection > useless. > > -- > -- Lukas > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 10 18:45:29 2010 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 10 Aug 2010 16:45:29 +0000 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: The trick to keeping an object alive isn't to call InitializeLifetimeService yourself but instead to return an appropriate lease. For example if you overrode InitializeLifetimeService in MbrBase to always return null your object will be kept alive forever. That will work fine as long as the app domain isn't living for an extremely long time or that you have a limited number of these MBROs that you're creating in the app domain. We still have this problem to solve in the DLR as well where we're still returning null. I think the correct solution is that we need to use ISponsor's (ClientSPonsor provides an implementation of this) on the client side and then call ILease.Register so the object can call back to your sponser. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Tuesday, August 10, 2010 6:43 AM To: Discussion of IronPython Subject: [IronPython] Query regarding Proxy Object lease period Hi, I posted this last week and I did not get a response.Hence posting it again. I have an application that creates a python engine in a new appdomain. If I do not specify a lease period I see that the objects are disconnected when I leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" to keep the object alive forever but it did not work. The "dlr-spec-hosting" document mentions the following in page 93 under "Current Issues" section : "Currently if you do not use a host for 15 min, it dies, and you lose your data. We've added InitializeLifetimeService on objects to cause them to stay alive forever, but we need to think through the design and the host controls here". Currently I renew the object using "ILease". I do not know if this is the right thing to do. Could you please suggest me the right way to deal with this issue. I have provided the code below for your reference. Thanks, Mustaq using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is this supposed to keep the object alive forever. lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one day. code.Execute(scope); // If the above lease is not mentioned then execution fails on this line after being inactive for 5 minutes. Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at prosysplus.com Tue Aug 10 20:49:21 2010 From: hank at prosysplus.com (Hank Fay) Date: Tue, 10 Aug 2010 14:49:21 -0400 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: References: <4C587947.3000307@bakalari.cz> Message-ID: Hi Vernon, have you looked at Microsoft.Data.Database, which comes with LightSwitch? I think it might have what you need in terms of methods and properties. It does require .Net 4.0. Hank On Tue, Aug 10, 2010 at 12:41 PM, Vernon Cole wrote: > I am afraid Lukas is very correct. (Thanks, you really saved me a lot of > debugging time.) > > This will be an anti-announcement. I got a version (2.4.1A1) of adodbapi > working (sort of) on ADO.NET and splatted up against enough difficulties > that I have shelved the effort for the present time. I have committed my > efforts to a new branch (named ado.net) on the mercurial source tree at > http://sourceforge.net/projects/adodbapi/develop for anyone who would like > to take up the effort. It might be worthwhile to continue development on an > SQL-server specific version, especially if someone has MONO in mind. Since > I intended adodbapi to be as universal as possible, I did not want to go > that direction. > > The problems I found were: > 1) Lukas was right -- only one datareader per connection. Messes up cursor > usage as per the api. > 2) cursor.rowcount becomes useless for SELECTs. > 3) Connection timeouts are only supported by adding text to the connection > strings -- which breaks JET. > 4) The "internal size" for cursor.description[3] cannot be retrieved. > 5) fine control of cursor location and isolation level is lost. > 6) MS documentation vaguely suggests that using ExecuteReader for a command > which returns no dataset is a bad idea, which may mean that there is a > problem with a stored procedure which may not return a dataset. > 7) MS documentation hints that schema results (which are processed into > cursor.description) may be incorrect unless a "keyinfo" flag is passed to > ExecuteReader, the use of which will cause several possible side effects to > the data retrieval. > 8) Use of a datareader implies no recordset, so I have to emulate a > recordset within my SQLrows object. > 9) ADO.NET still uses a COM interface internally to communicate with ADO > data adapters -- so what's the point of not using COM directly in my code > and keeping all of the lost features? > > So the COM implementation of adodbapi v2.4.0 will remain as the official > "latest and greatest" for IronPython. > > Thanks for all the fish... > Vernon Cole > > > On Tue, Aug 3, 2010 at 2:17 PM, Lukas Cenovsky wrote: > >> On 3.8.2010 1:24, Vernon Cole wrote: >> >> What are the consequences of using ExecuteReader() when there is >> nothing to read? If none, i.e. you get an empty set of results, then I >> would say to use that all the time, and don't bother to examine your >> SQL at all. >> >> >> I think ExecuteReader should work for everything. I use only ExecuteReader >> in my private tool (but I do not use stored procedures). >> >> You will have a bigger problem with ADO.NET than this. According to the >> Python dbapi specification, you can have as many cursors per connection as >> you want. You can have many cursors in ADO.NET too, but you can have only >> one SqlDataReader per connections which makes several cursors per connection >> useless. >> >> -- >> -- Lukas >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at kurtrichardson.com Tue Aug 10 21:43:44 2010 From: kurt at kurtrichardson.com (Kurt A Richardson) Date: Tue, 10 Aug 2010 12:43:44 -0700 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C609F46.5090604@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> <4C609F46.5090604@kurtrichardson.com> Message-ID: <4C61ABF0.6050807@kurtrichardson.com> Hi Dino I've switched windbg 64-bit into 32-bit mode ("!wow64exts.sw") and didn't get an output with any noticeable differences (see below). Any ideas? Thanks, Kurt ______________________________________________ Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" Symbol search path is: srv* Executable search path is: ModLoad: 00000000`2fd30000 00000000`2fdbe000 devenv.exe (1648.3308): Break instruction exception - code 80000003 (first chance) ntdll!LdrpDoDebuggerBreak+0x30: 00000000`77151340 cc int 3 0:000> !wow64exts.sw Switched to 32bit mode 0:000:x86> sxe ld clr.dll 0:000:x86> g (1648.3308): WOW64 breakpoint - code 4000001f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. ntdll32!LdrpDoDebuggerBreak+0x2c: 77320995 cc int 3 0:000:x86> .loadby sos clr Unable to find module 'clr' 0:000:x86> sxe -c "!pe; !ClrStack; g" clr 0:000:x86> sxe -c "kb30; g" eh 0:000:x86> .symfix 0:000:x86> .reload Reloading current modules ............................ 0:000:x86> g ModLoad: 00000000`63d60000 00000000`643cf000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll ntdll!ZwMapViewOfSection+0xa: 00000000`770effda c3 ret ______________________________________________ From kurt at kurtrichardson.com Tue Aug 10 21:48:29 2010 From: kurt at kurtrichardson.com (Kurt A Richardson) Date: Tue, 10 Aug 2010 12:48:29 -0700 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C61ABF0.6050807@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> <4C609F46.5090604@kurtrichardson.com> <4C61ABF0.6050807@kurtrichardson.com> Message-ID: <4C61AD0D.7020304@kurtrichardson.com> Hi Dino Maybe I should just try compiling the source locally. Do you know where I can find instructions to do this? Many thanks, Kurt From dinov at microsoft.com Tue Aug 10 22:45:38 2010 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 10 Aug 2010 20:45:38 +0000 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C61AD0D.7020304@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> <4C609F46.5090604@kurtrichardson.com> <4C61ABF0.6050807@kurtrichardson.com> <4C61AD0D.7020304@kurtrichardson.com> Message-ID: Kurt wrote: > Hi Dino > > Maybe I should just try compiling the source locally. Do you know where > I can find instructions to do this? > If you're willing to build from source that's great. Do you have VS 2010 Pro or above? You'll need it to build from VS but I think you can just do Msbuild from the command line w/o it (haven't tried that though). Either way You'll need to install the VS SDK (http://www.microsoft.com/downloads/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en) >From there it should be as simple as downloading the source from the Source Code tab on Codeplex and then opening IronPython_Main\Solutions\IronPythonTools.sln. You might also need to copy IronPython binaries into IronPython_Main\Tools\IronStudio\Bin (we have those checked into our tree but for some reason they don't propagate out). If you have VS Pro to run this you'll want to right click on the IronPythonTools project select properties, and change the Debug tab to Start external program, run devenv.exe (C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe), and then change the command line arguments to be "/rootsuffix Exp /log". At that point F5 will simply work and launch VS under VS and life should be good. If you run into any problems let me know - you may be the 1st person trying to build externally. From dinov at microsoft.com Tue Aug 10 22:46:41 2010 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 10 Aug 2010 20:46:41 +0000 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C61ABF0.6050807@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> <4C609F46.5090604@kurtrichardson.com> <4C61ABF0.6050807@kurtrichardson.com> Message-ID: My guess on this is that maybe !wow64exts.sw may not be the same as using the 32-bit debugger. I myself haven't done much WOW debugging - I just use the 32-bit debugger on my 64-bit OS and all works well. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Kurt A Richardson > Sent: Tuesday, August 10, 2010 12:44 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] Trouble with IP 7.0 and VS 2010 > > Hi Dino > > I've switched windbg 64-bit into 32-bit mode ("!wow64exts.sw") and > didn't get an output with any noticeable differences (see below). Any > ideas? > > Thanks, Kurt > > ______________________________________________ > > Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 > Copyright (c) Microsoft Corporation. All rights reserved. > > CommandLine: "C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\IDE\devenv.exe" > Symbol search path is: srv* > Executable search path is: > ModLoad: 00000000`2fd30000 00000000`2fdbe000 devenv.exe > (1648.3308): Break instruction exception - code 80000003 (first chance) > ntdll!LdrpDoDebuggerBreak+0x30: > 00000000`77151340 cc int 3 > 0:000> !wow64exts.sw > Switched to 32bit mode > 0:000:x86> sxe ld clr.dll > 0:000:x86> g > (1648.3308): WOW64 breakpoint - code 4000001f (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > ntdll32!LdrpDoDebuggerBreak+0x2c: > 77320995 cc int 3 > 0:000:x86> .loadby sos clr > Unable to find module 'clr' > 0:000:x86> sxe -c "!pe; !ClrStack; g" clr > 0:000:x86> sxe -c "kb30; g" eh > 0:000:x86> .symfix > 0:000:x86> .reload > Reloading current modules > ............................ > 0:000:x86> g > ModLoad: 00000000`63d60000 00000000`643cf000 > C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll > ntdll!ZwMapViewOfSection+0xa: > 00000000`770effda c3 ret > > ______________________________________________ > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From mustaq2001 at gmail.com Wed Aug 11 16:29:30 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Wed, 11 Aug 2010 19:59:30 +0530 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: I did override "InitializeLifetimeService" in MbrBase to return null. But in my example the "scope" object dies at first instance, so how would overriding "InitializeLifetimeService" in MbrBase help. Could you please modify my code to illustrate the right usage of ISponsor on the client side. My application will create objects periodically in the appdomain and execute methods implemented in IronPython. These methods may take around 20 minutes to execute. The whole application may run for a day or more. So I need to take this into consideration while implementing the lifetime service. I needed to confirm one thing. Do i need to provide the lease period for all objects created in the Appdomain. As per the code given below do i need to provide the lease period for "code","scope","mbr","script", "ops" etc. Or is it only based on how long I expect the object to be alive. I am new to this concept of Appdomain hence my questions may sound silly. On Tue, Aug 10, 2010 at 10:15 PM, Dino Viehland wrote: > The trick to keeping an object alive isn?t to call > InitializeLifetimeService yourself but instead to return an appropriate > lease. For example if you overrode InitializeLifetimeService in MbrBase to > always return null your object will be kept alive forever. That will work > fine as long as the app domain isn?t living for an extremely long time or > that you have a limited number of these MBROs that you?re creating in the > app domain. > > > > We still have this problem to solve in the DLR as well where we?re still > returning null. I think the correct solution is that we need to use > ISponsor?s (ClientSPonsor provides an implementation of this) on the client > side and then call ILease.Register so the object can call back to your > sponser. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Tuesday, August 10, 2010 6:43 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Query regarding Proxy Object lease period > > > > > > Hi, > > I posted this last week and I did not get a response.Hence posting it > again. > > I have an application that creates a python engine in a new appdomain. If I > do not specify a lease period I see that the objects are disconnected when I > leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" > to keep the object alive forever but it did not work. The "dlr-spec-hosting" > document mentions the following in page 93 under "Current Issues" section : > "Currently if you do not use a host for 15 min, it dies, and you lose your > data. We've added InitializeLifetimeService on objects to cause them to stay > alive forever, but we need to think through the design and the host controls > here". Currently I renew the object using "ILease". I do not know if this is > the right thing to do. Could you please suggest me the right way to deal > with this issue. I have provided the code below for your reference. > > Thanks, > Mustaq > > using System; > using Microsoft.Scripting; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > using System.Runtime.Remoting; > using System.Runtime.Remoting.Lifetime; > > class Foo > { > public static void Main(string[] args) > { > AppDomain ad = AppDomain.CreateDomain("foo"); > ScriptEngine engine = Python.CreateEngine(ad); > engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); > > ScriptSource code = engine.CreateScriptSourceFromString(@" > import MbrBase > class C(MbrBase): > def Test_C(self, log): > print 0 > a = C() > ", SourceCodeKind.Statements); > > ScriptScope scope = engine.CreateScope(); > ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is > this supposed to keep the object alive forever. > > lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one > day. > code.Execute(scope); // If the above lease is not mentioned then > execution fails on this line after being inactive for 5 minutes. > > Console.WriteLine("Trying to do it... {0}", > AppDomain.CurrentDomain.Id); > MbrBase mbr = (MbrBase)scope.GetVariable("a"); > > string isSubClassCode = String.Format("issubclass({0},{1})", "C", > "MbrBase"); > ScriptSource script = > engine.CreateScriptSourceFromString(isSubClassCode, > SourceCodeKind.Expression); > bool result = (bool)script.Execute(scope); > > if (result == true) > { > ObjectOperations ops = engine.Operations; > ObjectHandle subClass = scope.GetVariableHandle("C"); // get > back a handle > ObjectHandle instance = ops.Call(subClass, new > ObjectHandle[0]); // invoke the handle to create an instance > mbr = instance.Unwrap() as MbrBase; // now we know we have an > MBR and we can unwrap it to our local side > > ObjectHandle temp = ops.GetMember(instance, "Test_C"); > object log = null; > ops.Call(temp, log); > } > > mbr.DoItVirtually(); > mbr.DoIt(); > Console.ReadKey(); > } > } > > public class MbrBase : MarshalByRefObject > { > public virtual void DoItVirtually() > { > Console.WriteLine("Did it virtually {0}", > AppDomain.CurrentDomain.Id); > } > > public void DoIt() > { > Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); > } > } > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at kurtrichardson.com Wed Aug 11 17:24:51 2010 From: kurt at kurtrichardson.com (Kurt A. Richardson) Date: Wed, 11 Aug 2010 08:24:51 -0700 Subject: [IronPython] Trouble with IP 7.0 and VS 2010 In-Reply-To: <4C61AD0D.7020304@kurtrichardson.com> References: <4C6064E9.9050206@kurtrichardson.com> <4C609E2F.4070201@kurtrichardson.com> <4C609F46.5090604@kurtrichardson.com> <4C61ABF0.6050807@kurtrichardson.com> <4C61AD0D.7020304@kurtrichardson.com> Message-ID: <4C62C0C3.7090203@kurtrichardson.com> Hi Dino I remembered last night that I'd installed VS 2010 Pro over an RC version. Of course uninstalling VS never really seems to remove everything, so I did a clean install of my OS and VS 2010, and now IronPython integrations with VS 'seems' to be working. Not sure why I forgot this important guideline when messing around with RCs ;-) I will still try to build externally, just for the fun of it! Thanks for all your guidance. Bye for now, Kurt From merllab at microsoft.com Wed Aug 11 17:38:44 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 11 Aug 2010 08:38:44 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <09f7484d-bab6-4a57-98a2-9d071e6ee169@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75347. ADDED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/BuiltinPythonModule.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/InstancedModuleDictionaryStorage.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/TestBuiltinModule.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython/IronPython.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/BuiltinPythonModule.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/CustomDictionaryStorage.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/InstancedModuleDictionaryStorage.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ModuleDictionaryStorage.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/MetaBuiltinFunction.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Types/BuiltinFunction.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Types/DocBuilder.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Types/FunctionType.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/IronPythonTest.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/TestBuiltinModule.cs $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_imp.py CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1967242 Date: 8/10/2010 9:57:20 PM Adds a new way of implementing built-in modules by subclassing PythonBuiltinModule class. This enables having a module which has an instance associated with it rather than having a bunch of static method definitions. We?ll create the instance for the PythonContext when the module gets imported. The instance can include various fields which enable quick access to the module. This was requested to help get fast module access for Cython-like support for IronPython. (Shelveset: NewBuiltinModulefinal;REDMOND\dinov | SNAP CheckinId: 11255) From evans.d.andrew at gmail.com Wed Aug 11 18:34:58 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Wed, 11 Aug 2010 09:34:58 -0700 Subject: [IronPython] IronPython Silverlight 4 debugging... [No errors just not working] Message-ID: Hello I am running IronPython 2.7A and trying to debug a Silverlight app. I am trying to figure out why my ship doesn't move when I press the Arrow keys. here is the complete source minus most imports :D Any ideas from System.Windows.Input import * velocity = 10 class Gui(): def __init__(self): self.grid = Grid() self.canvas = Canvas(Background = SolidColorBrush(Colors.White)) self.canvas.Width = 640 self.canvas.Height = 432 self.bgImage = Image( Source = BitmapImage(Uri("images/background.jpg", UriKind.Relative)) ) self.canvas.SetTop(self.bgImage, 132) self.canvas.SetLeft(self.bgImage, 0) # self.textblock = TextBlock() ## self.textblock.FontSize = 24 ## self.textblock.Text = 'This Really Works!!' ## self.canvas.Children.Add(self.textblock) self.ship = Image( Source = BitmapImage(Uri("images/ship.png", UriKind.Relative)) ) self.canvas.SetTop(self.ship, 75) self.canvas.SetLeft(self.ship, 25) CompositionTarget.Rendering += EventHandler(self.ShootBG) ## self.GenerateStarField(350) self.canvas.Children.Add(self.bgImage) self.canvas.Children.Add(self.ship) self.grid.Children.Add(self.canvas) Application.Current.RootVisual = self.grid # This line should be something different Not sure what to use instead of this self.ship.KeyDown += KeyEventHandler(self.KeyDown_Control) def ShootBG(self, s, e): self.canvas.SetLeft(self.bgImage, self.canvas.GetLeft(self.bgImage) - 1) if self.canvas.GetLeft(self.bgImage) < -2110: self.canvas.SetLeft(self.bgImage, 0) def KeyDown_Control(self, s, e): if e.Key == Key.Right: self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) + velocity) elif e.Key == Key.Left: self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) - velocity) elif e.Key == Key.Up: self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) - velocity) elif e.Key == Key.Down: self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) + velocity) gui = Gui() gui -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Wed Aug 11 18:37:02 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 11 Aug 2010 17:37:02 +0100 Subject: [IronPython] IronPython Silverlight 4 debugging... [No errors just not working] In-Reply-To: References: Message-ID: <4C62D1AE.2000904@voidspace.org.uk> On 11/08/2010 17:34, Andrew Evans wrote: > Hello I am running IronPython 2.7A and trying to debug a Silverlight > app. I am trying to figure out why my ship doesn't move when I press > the Arrow keys. > > here is the complete source minus most imports :D Put some debugging in (append text to an html div) to see if your event handlers are being fired. That would my first step. Michael > > Any ideas > > from System.Windows.Input import * > > > velocity = 10 > > class Gui(): > def __init__(self): > > self.grid = Grid() > self.canvas = Canvas(Background = SolidColorBrush(Colors.White)) > self.canvas.Width = 640 > self.canvas.Height = 432 > self.bgImage = Image( > Source = BitmapImage(Uri("images/background.jpg", > UriKind.Relative)) > ) > self.canvas.SetTop(self.bgImage, 132) > self.canvas.SetLeft(self.bgImage, 0) > # self.textblock = TextBlock() > ## self.textblock.FontSize = 24 > ## self.textblock.Text = 'This Really Works!!' > ## self.canvas.Children.Add(self.textblock) > > self.ship = Image( > Source = BitmapImage(Uri("images/ship.png", UriKind.Relative)) > ) > > self.canvas.SetTop(self.ship, 75) > self.canvas.SetLeft(self.ship, 25) > > CompositionTarget.Rendering += EventHandler(self.ShootBG) > ## self.GenerateStarField(350) > > self.canvas.Children.Add(self.bgImage) > > self.canvas.Children.Add(self.ship) > self.grid.Children.Add(self.canvas) > Application.Current.RootVisual = self.grid > # This line should be something different Not sure what to use > instead of this > self.ship.KeyDown += KeyEventHandler(self.KeyDown_Control) > > > def ShootBG(self, s, e): > self.canvas.SetLeft(self.bgImage, > self.canvas.GetLeft(self.bgImage) - 1) > if self.canvas.GetLeft(self.bgImage) < -2110: > self.canvas.SetLeft(self.bgImage, 0) > > def KeyDown_Control(self, s, e): > if e.Key == Key.Right: > self.canvas.SetLeft(self.ship, > self.canvas.GetLeft(self.ship) + velocity) > elif e.Key == Key.Left: > self.canvas.SetLeft(self.ship, > self.canvas.GetLeft(self.ship) - velocity) > elif e.Key == Key.Up: > self.canvas.SetTop(self.ship, > self.canvas.GetTop(self.ship) - velocity) > elif e.Key == Key.Down: > self.canvas.SetTop(self.ship, > self.canvas.GetTop(self.ship) + velocity) > > gui = Gui() > gui > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Aug 11 18:56:43 2010 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 11 Aug 2010 16:56:43 +0000 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: What version of IronPython are you using? When I try this against 2.6.1 ScriptScope is "properly" returning null. I would recommend seeing how the lifetime issue stacks up w/ everything returning null. I think long term we need to provide an API that lets you provide the sponsors for hosting API objects but until we do that leasing your own objects may be futile unless there a whole lot of them in comparison to the hosting API objects. I actually haven't done the leasing stuff myself either so I'm not sure I can quickly cook up an example. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Wednesday, August 11, 2010 7:30 AM To: Discussion of IronPython Subject: Re: [IronPython] Query regarding Proxy Object lease period I did override "InitializeLifetimeService" in MbrBase to return null. But in my example the "scope" object dies at first instance, so how would overriding "InitializeLifetimeService" in MbrBase help. Could you please modify my code to illustrate the right usage of ISponsor on the client side. My application will create objects periodically in the appdomain and execute methods implemented in IronPython. These methods may take around 20 minutes to execute. The whole application may run for a day or more. So I need to take this into consideration while implementing the lifetime service. I needed to confirm one thing. Do i need to provide the lease period for all objects created in the Appdomain. As per the code given below do i need to provide the lease period for "code","scope","mbr","script", "ops" etc. Or is it only based on how long I expect the object to be alive. I am new to this concept of Appdomain hence my questions may sound silly. On Tue, Aug 10, 2010 at 10:15 PM, Dino Viehland > wrote: The trick to keeping an object alive isn't to call InitializeLifetimeService yourself but instead to return an appropriate lease. For example if you overrode InitializeLifetimeService in MbrBase to always return null your object will be kept alive forever. That will work fine as long as the app domain isn't living for an extremely long time or that you have a limited number of these MBROs that you're creating in the app domain. We still have this problem to solve in the DLR as well where we're still returning null. I think the correct solution is that we need to use ISponsor's (ClientSPonsor provides an implementation of this) on the client side and then call ILease.Register so the object can call back to your sponser. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Tuesday, August 10, 2010 6:43 AM To: Discussion of IronPython Subject: [IronPython] Query regarding Proxy Object lease period Hi, I posted this last week and I did not get a response.Hence posting it again. I have an application that creates a python engine in a new appdomain. If I do not specify a lease period I see that the objects are disconnected when I leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" to keep the object alive forever but it did not work. The "dlr-spec-hosting" document mentions the following in page 93 under "Current Issues" section : "Currently if you do not use a host for 15 min, it dies, and you lose your data. We've added InitializeLifetimeService on objects to cause them to stay alive forever, but we need to think through the design and the host controls here". Currently I renew the object using "ILease". I do not know if this is the right thing to do. Could you please suggest me the right way to deal with this issue. I have provided the code below for your reference. Thanks, Mustaq using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is this supposed to keep the object alive forever. lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one day. code.Execute(scope); // If the above lease is not mentioned then execution fails on this line after being inactive for 5 minutes. Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From evans.d.andrew at gmail.com Wed Aug 11 19:11:01 2010 From: evans.d.andrew at gmail.com (Andrew Evans) Date: Wed, 11 Aug 2010 10:11:01 -0700 Subject: [IronPython] IronPython Silverlight 4 debugging... [No errors just not working] In-Reply-To: <4C62D1AE.2000904@voidspace.org.uk> References: <4C62D1AE.2000904@voidspace.org.uk> Message-ID: Ok well it doesn't look like my event handlers are even being called this is what I did def KeyDown_Control(self, s, e): if e.Key == Key.Right: print "Right Arrow" #self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) + velocity) elif e.Key == Key.Left: print "Left Arrow" #self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) - velocity) elif e.Key == Key.Up: print "Up Arrow" #self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) - velocity) elif e.Key == Key.Down: print "Down Arrow" #self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) + velocity) So assuming that's the issue which is likely than it would be this line # This line should be something different Not sure what to use instead of this self.ship.KeyDown += KeyEventHandler(self.KeyDown_Control) Which I assumed all this time Any ideas what it should be? *cheers Andrew On Wed, Aug 11, 2010 at 9:37 AM, Michael Foord wrote: > On 11/08/2010 17:34, Andrew Evans wrote: > > Hello I am running IronPython 2.7A and trying to debug a Silverlight app. I > am trying to figure out why my ship doesn't move when I press the Arrow > keys. > > here is the complete source minus most imports :D > > Put some debugging in (append text to an html div) to see if your event > handlers are being fired. That would my first step. > > Michael > > > Any ideas > > from System.Windows.Input import * > > > velocity = 10 > > class Gui(): > def __init__(self): > > self.grid = Grid() > self.canvas = Canvas(Background = SolidColorBrush(Colors.White)) > self.canvas.Width = 640 > self.canvas.Height = 432 > self.bgImage = Image( > Source = BitmapImage(Uri("images/background.jpg", > UriKind.Relative)) > ) > self.canvas.SetTop(self.bgImage, 132) > self.canvas.SetLeft(self.bgImage, 0) > # self.textblock = TextBlock() > ## self.textblock.FontSize = 24 > ## self.textblock.Text = 'This Really Works!!' > ## self.canvas.Children.Add(self.textblock) > > self.ship = Image( > Source = BitmapImage(Uri("images/ship.png", UriKind.Relative)) > ) > > self.canvas.SetTop(self.ship, 75) > self.canvas.SetLeft(self.ship, 25) > > CompositionTarget.Rendering += EventHandler(self.ShootBG) > ## self.GenerateStarField(350) > > self.canvas.Children.Add(self.bgImage) > > self.canvas.Children.Add(self.ship) > self.grid.Children.Add(self.canvas) > Application.Current.RootVisual = self.grid > # This line should be something different Not sure what to use > instead of this > self.ship.KeyDown += KeyEventHandler(self.KeyDown_Control) > > > def ShootBG(self, s, e): > self.canvas.SetLeft(self.bgImage, self.canvas.GetLeft(self.bgImage) > - 1) > if self.canvas.GetLeft(self.bgImage) < -2110: > self.canvas.SetLeft(self.bgImage, 0) > > def KeyDown_Control(self, s, e): > if e.Key == Key.Right: > self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) + > velocity) > elif e.Key == Key.Left: > self.canvas.SetLeft(self.ship, self.canvas.GetLeft(self.ship) - > velocity) > elif e.Key == Key.Up: > self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) - > velocity) > elif e.Key == Key.Down: > self.canvas.SetTop(self.ship, self.canvas.GetTop(self.ship) + > velocity) > > gui = Gui() > gui > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > -- http://www.ironpythoninaction.com/http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Wed Aug 11 19:19:56 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 11 Aug 2010 11:19:56 -0600 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: References: <4C587947.3000307@bakalari.cz> Message-ID: Hank: Never heard of it (before). A quick search of google and msdn only tells me that LightSwitch is soon to be released in beta. As a full time college student (how did I get myself into this at the age of 60?) I can get access to lots of free, new, and beta stuff. Do you have links? (send privately if need be.) -- Vernon On Tue, Aug 10, 2010 at 12:49 PM, Hank Fay wrote: > Hi Vernon, > > have you looked at Microsoft.Data.Database, which comes with LightSwitch? > I think it might have what you need in terms of methods and properties. It > does require .Net 4.0. > > Hank > > > On Tue, Aug 10, 2010 at 12:41 PM, Vernon Cole wrote: > >> I am afraid Lukas is very correct. (Thanks, you really saved me a lot of >> debugging time.) >> >> This will be an anti-announcement. I got a version (2.4.1A1) of adodbapi >> working (sort of) on ADO.NET and splatted up against enough difficulties >> that I have shelved the effort for the present time. I have committed my >> efforts to a new branch (named ado.net) on the mercurial source tree at >> http://sourceforge.net/projects/adodbapi/develop for anyone who would >> like to take up the effort. It might be worthwhile to continue development >> on an SQL-server specific version, especially if someone has MONO in mind. >> Since I intended adodbapi to be as universal as possible, I did not want to >> go that direction. >> >> The problems I found were: >> 1) Lukas was right -- only one datareader per connection. Messes up cursor >> usage as per the api. >> 2) cursor.rowcount becomes useless for SELECTs. >> 3) Connection timeouts are only supported by adding text to the connection >> strings -- which breaks JET. >> 4) The "internal size" for cursor.description[3] cannot be retrieved. >> 5) fine control of cursor location and isolation level is lost. >> 6) MS documentation vaguely suggests that using ExecuteReader for a >> command which returns no dataset is a bad idea, which may mean that there is >> a problem with a stored procedure which may not return a dataset. >> 7) MS documentation hints that schema results (which are processed into >> cursor.description) may be incorrect unless a "keyinfo" flag is passed to >> ExecuteReader, the use of which will cause several possible side effects to >> the data retrieval. >> 8) Use of a datareader implies no recordset, so I have to emulate a >> recordset within my SQLrows object. >> 9) ADO.NET still uses a COM interface internally to communicate with ADO >> data adapters -- so what's the point of not using COM directly in my code >> and keeping all of the lost features? >> >> So the COM implementation of adodbapi v2.4.0 will remain as the official >> "latest and greatest" for IronPython. >> >> Thanks for all the fish... >> Vernon Cole >> >> >> On Tue, Aug 3, 2010 at 2:17 PM, Lukas Cenovsky wrote: >> >>> On 3.8.2010 1:24, Vernon Cole wrote: >>> >>> What are the consequences of using ExecuteReader() when there is >>> nothing to read? If none, i.e. you get an empty set of results, then I >>> would say to use that all the time, and don't bother to examine your >>> SQL at all. >>> >>> >>> I think ExecuteReader should work for everything. I use only >>> ExecuteReader in my private tool (but I do not use stored procedures). >>> >>> You will have a bigger problem with ADO.NET than this. According to the >>> Python dbapi specification, you can have as many cursors per connection as >>> you want. You can have many cursors in ADO.NET too, but you can have >>> only one SqlDataReader per connections which makes several cursors per >>> connection useless. >>> >>> -- >>> -- Lukas >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Wed Aug 11 19:21:57 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Wed, 11 Aug 2010 19:21:57 +0200 Subject: [IronPython] IronPython Silverlight 4 debugging... [No errors just not working] In-Reply-To: References: <4C62D1AE.2000904@voidspace.org.uk> Message-ID: <4C62DC35.5010009@bakalari.cz> On 11.8.2010 19:11, Andrew Evans wrote: > Ok well it doesn't look like my event handlers are even being called > > this is what I did > > def KeyDown_Control(self, s, e): > if e.Key == Key.Right: > print "Right Arrow" > #self.canvas.SetLeft(self.ship, > self.canvas.GetLeft(self.ship) + velocity) > elif e.Key == Key.Left: > print "Left Arrow" > #self.canvas.SetLeft(self.ship, > self.canvas.GetLeft(self.ship) - velocity) > elif e.Key == Key.Up: > print "Up Arrow" > #self.canvas.SetTop(self.ship, > self.canvas.GetTop(self.ship) - velocity) > elif e.Key == Key.Down: > print "Down Arrow" > #self.canvas.SetTop(self.ship, > self.canvas.GetTop(self.ship) + velocity) > > So assuming that's the issue which is likely than it would be this line > > # This line should be something different Not sure what to use instead > of this > self.ship.KeyDown += KeyEventHandler(self.KeyDown_Control) What about self.ship.KeyDown += self.KeyDown_Control -- -- Lukas > > Which I assumed all this time > > Any ideas what it should be? > > *cheers > > Andrew > > On Wed, Aug 11, 2010 at 9:37 AM, Michael Foord > > wrote: > > On 11/08/2010 17:34, Andrew Evans wrote: >> Hello I am running IronPython 2.7A and trying to debug a >> Silverlight app. I am trying to figure out why my ship doesn't >> move when I press the Arrow keys. >> >> here is the complete source minus most imports :D > Put some debugging in (append text to an html div) to see if your > event handlers are being fired. That would my first step. > > Michael > >> >> Any ideas >> >> from System.Windows.Input import * >> >> >> velocity = 10 >> >> class Gui(): >> def __init__(self): >> >> self.grid = Grid() >> self.canvas = Canvas(Background = >> SolidColorBrush(Colors.White)) >> self.canvas.Width = 640 >> self.canvas.Height = 432 >> self.bgImage = Image( >> Source = BitmapImage(Uri("images/background.jpg", >> UriKind.Relative)) >> ) >> self.canvas.SetTop(self.bgImage, 132) >> self.canvas.SetLeft(self.bgImage, 0) >> # self.textblock = TextBlock() >> ## self.textblock.FontSize = 24 >> ## self.textblock.Text = 'This Really Works!!' >> ## self.canvas.Children.Add(self.textblock) >> >> self.ship = Image( >> Source = BitmapImage(Uri("images/ship.png", >> UriKind.Relative)) >> ) >> >> self.canvas.SetTop(self.ship, 75) >> self.canvas.SetLeft(self.ship, 25) >> >> CompositionTarget.Rendering += EventHandler(self.ShootBG) >> ## self.GenerateStarField(350) >> >> self.canvas.Children.Add(self.bgImage) >> >> self.canvas.Children.Add(self.ship) >> self.grid.Children.Add(self.canvas) >> Application.Current.RootVisual = self.grid >> # This line should be something different Not sure what >> to use instead of this >> self.ship.KeyDown += KeyEventHandler(self.KeyDown_Control) >> >> >> def ShootBG(self, s, e): >> self.canvas.SetLeft(self.bgImage, >> self.canvas.GetLeft(self.bgImage) - 1) >> if self.canvas.GetLeft(self.bgImage) < -2110: >> self.canvas.SetLeft(self.bgImage, 0) >> >> def KeyDown_Control(self, s, e): >> if e.Key == Key.Right: >> self.canvas.SetLeft(self.ship, >> self.canvas.GetLeft(self.ship) + velocity) >> elif e.Key == Key.Left: >> self.canvas.SetLeft(self.ship, >> self.canvas.GetLeft(self.ship) - velocity) >> elif e.Key == Key.Up: >> self.canvas.SetTop(self.ship, >> self.canvas.GetTop(self.ship) - velocity) >> elif e.Key == Key.Down: >> self.canvas.SetTop(self.ship, >> self.canvas.GetTop(self.ship) + velocity) >> >> gui = Gui() >> gui >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Wed Aug 11 20:17:47 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Wed, 11 Aug 2010 20:17:47 +0200 Subject: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query? In-Reply-To: References: <4C587947.3000307@bakalari.cz> Message-ID: <4C62E94B.3080608@bakalari.cz> He is probably talking about this: http://weblogs.asp.net/davidfowler/archive/2010/08/02/introduction-to-microsoft-data-dll.aspx From reading the article, I don't think it is the way to go. -- -- Lukas On 11.8.2010 19:19, Vernon Cole wrote: > Hank: > Never heard of it (before). A quick search of google and msdn only > tells me that LightSwitch is soon to be released in beta. As a full > time college student (how did I get myself into this at the age of > 60?) I can get access to lots of free, new, and beta stuff. Do you > have links? > (send privately if need be.) > -- > Vernon > > On Tue, Aug 10, 2010 at 12:49 PM, Hank Fay > wrote: > > Hi Vernon, > > have you looked at Microsoft.Data.Database, which comes with > LightSwitch? I think it might have what you need in terms of > methods and properties. It does require .Net 4.0. > > Hank > > > On Tue, Aug 10, 2010 at 12:41 PM, Vernon Cole > > wrote: > > I am afraid Lukas is very correct. (Thanks, you really saved > me a lot of debugging time.) > > This will be an anti-announcement. I got a version (2.4.1A1) > of adodbapi working (sort of) on ADO.NET and > splatted up against enough difficulties that I have shelved > the effort for the present time. I have committed my efforts > to a new branch (named ado.net ) on the > mercurial source tree at > http://sourceforge.net/projects/adodbapi/develop for anyone > who would like to take up the effort. It might be worthwhile > to continue development on an SQL-server specific version, > especially if someone has MONO in mind. Since I intended > adodbapi to be as universal as possible, I did not want to go > that direction. > > The problems I found were: > 1) Lukas was right -- only one datareader per connection. > Messes up cursor usage as per the api. > 2) cursor.rowcount becomes useless for SELECTs. > 3) Connection timeouts are only supported by adding text to > the connection strings -- which breaks JET. > 4) The "internal size" for cursor.description[3] cannot be > retrieved. > 5) fine control of cursor location and isolation level is lost. > 6) MS documentation vaguely suggests that using ExecuteReader > for a command which returns no dataset is a bad idea, which > may mean that there is a problem with a stored procedure which > may not return a dataset. > 7) MS documentation hints that schema results (which are > processed into cursor.description) may be incorrect unless a > "keyinfo" flag is passed to ExecuteReader, the use of which > will cause several possible side effects to the data retrieval. > 8) Use of a datareader implies no recordset, so I have to > emulate a recordset within my SQLrows object. > 9) ADO.NET still uses a COM interface > internally to communicate with ADO data adapters -- so what's > the point of not using COM directly in my code and keeping all > of the lost features? > > So the COM implementation of adodbapi v2.4.0 will remain as > the official "latest and greatest" for IronPython. > > Thanks for all the fish... > Vernon Cole > > > On Tue, Aug 3, 2010 at 2:17 PM, Lukas Cenovsky > > wrote: > > On 3.8.2010 1:24, Vernon Cole wrote: >> What are the consequences of using ExecuteReader() when >> there is >> nothing to read? If none, i.e. you get an empty set of >> results, then I >> would say to use that all the time, and don't bother to >> examine your >> SQL at all. >> > > I think ExecuteReader should work for everything. I use > only ExecuteReader in my private tool (but I do not use > stored procedures). > > You will have a bigger problem with ADO.NET > than this. According to the Python dbapi > specification, you can have as many cursors per connection > as you want. You can have many cursors in ADO.NET > too, but you can have only one > SqlDataReader per connections which makes several cursors > per connection useless. > > -- > -- Lukas > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhoward42 at gmail.com Thu Aug 12 00:54:01 2010 From: peterhoward42 at gmail.com (Peter Howard) Date: Wed, 11 Aug 2010 23:54:01 +0100 Subject: [IronPython] newbie getting started problem In-Reply-To: References: Message-ID: I've eventually found what was wrong myself, but will post it here to potentially help other newcomers: The Python code was fine, the problem lay in the html. Specifically the default behaviour of this: is to make the Silverlight control just one pixel wide, and one pixel tall - and thus you cannot see any Silverlight graphics you subsequently add. So to fix it, you pre-initialise the control's width and height settings before running dlr-latest.js as shown in this complete html example: -------------- next part -------------- An HTML attachment was scrubbed... URL: From yngipy at gmail.com Thu Aug 12 04:20:31 2010 From: yngipy at gmail.com (yngipy hernan) Date: Wed, 11 Aug 2010 21:20:31 -0500 Subject: [IronPython] Calling COM method returns generic System.__ComObject? Message-ID: Hi All, I have been playing around IronPython + COM + OPC (COM not the .Net). One of the calls in OPC is (pseudocode): item = opc_items_object.AddItem('OPC path here', opc_grp_object.ClientHandle) The issue is that item is returned as System.__ComObject. All methods that are available for OPCItem interface are gone??? I have search the internet and it seems like opc_items_object should have a coclass for IronPython to figure out how to return object properly. Unfortunately this is not the case, based on the IDL OPCItems don't have a coclass definition. Is there a work-around for this? I have also come across a possible work-around by using unbound class instance, i.e., outParamAsReturnValue = InteropAssemblyNamespace.IComInterface(comObject). But I can't figure out how to use it. I would really appreciate anyone can point me out to the right direction. Regards, Yngipy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustaq2001 at gmail.com Thu Aug 12 04:25:28 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Thu, 12 Aug 2010 07:55:28 +0530 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: I am using IronPython 2.0.When you said ScriptScope is returning null did you mean ScriptScope.InitializeLifetimeService() is returning null. So do you mean to say that overriding "InitializeLifetimeService" in MbrBase is sufficient to keep the hosting API objects alive. On Wed, Aug 11, 2010 at 10:26 PM, Dino Viehland wrote: > What version of IronPython are you using? When I try this against 2.6.1 > ScriptScope is ?properly? returning null. I would recommend seeing how > the lifetime issue stacks up w/ everything returning null. I think long > term we need to provide an API that lets you provide the sponsors for > hosting API objects but until we do that leasing your own objects may be > futile unless there a whole lot of them in comparison to the hosting API > objects. I actually haven?t done the leasing stuff myself either so I?m > not sure I can quickly cook up an example. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Wednesday, August 11, 2010 7:30 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Query regarding Proxy Object lease period > > > > > I did override "InitializeLifetimeService" in MbrBase to return null. But > in my example the "scope" object dies at first instance, so how would > overriding "InitializeLifetimeService" in MbrBase help. Could you please > modify my code to illustrate the right usage of ISponsor on the client side. > > > My application will create objects periodically in the appdomain and > execute methods implemented in IronPython. These methods may take around 20 > minutes to execute. The whole application may run for a day or more. So I > need to take this into consideration while implementing the lifetime > service. > > I needed to confirm one thing. Do i need to provide the lease period for > all objects created in the Appdomain. As per the code given below do i need > to provide the lease period for "code","scope","mbr","script", "ops" etc. > Or is it only based on how long I expect the object to be alive. > > I am new to this concept of Appdomain hence my questions may sound silly. > > On Tue, Aug 10, 2010 at 10:15 PM, Dino Viehland > wrote: > > The trick to keeping an object alive isn?t to call > InitializeLifetimeService yourself but instead to return an appropriate > lease. For example if you overrode InitializeLifetimeService in MbrBase to > always return null your object will be kept alive forever. That will work > fine as long as the app domain isn?t living for an extremely long time or > that you have a limited number of these MBROs that you?re creating in the > app domain. > > > > We still have this problem to solve in the DLR as well where we?re still > returning null. I think the correct solution is that we need to use > ISponsor?s (ClientSPonsor provides an implementation of this) on the client > side and then call ILease.Register so the object can call back to your > sponser. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Tuesday, August 10, 2010 6:43 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Query regarding Proxy Object lease period > > > > > > Hi, > > I posted this last week and I did not get a response.Hence posting it > again. > > I have an application that creates a python engine in a new appdomain. If I > do not specify a lease period I see that the objects are disconnected when I > leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" > to keep the object alive forever but it did not work. The "dlr-spec-hosting" > document mentions the following in page 93 under "Current Issues" section : > "Currently if you do not use a host for 15 min, it dies, and you lose your > data. We've added InitializeLifetimeService on objects to cause them to stay > alive forever, but we need to think through the design and the host controls > here". Currently I renew the object using "ILease". I do not know if this is > the right thing to do. Could you please suggest me the right way to deal > with this issue. I have provided the code below for your reference. > > Thanks, > Mustaq > > using System; > using Microsoft.Scripting; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > using System.Runtime.Remoting; > using System.Runtime.Remoting.Lifetime; > > class Foo > { > public static void Main(string[] args) > { > AppDomain ad = AppDomain.CreateDomain("foo"); > ScriptEngine engine = Python.CreateEngine(ad); > engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); > > ScriptSource code = engine.CreateScriptSourceFromString(@" > import MbrBase > class C(MbrBase): > def Test_C(self, log): > print 0 > a = C() > ", SourceCodeKind.Statements); > > ScriptScope scope = engine.CreateScope(); > ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is > this supposed to keep the object alive forever. > > lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one > day. > code.Execute(scope); // If the above lease is not mentioned then > execution fails on this line after being inactive for 5 minutes. > > Console.WriteLine("Trying to do it... {0}", > AppDomain.CurrentDomain.Id); > MbrBase mbr = (MbrBase)scope.GetVariable("a"); > > string isSubClassCode = String.Format("issubclass({0},{1})", "C", > "MbrBase"); > ScriptSource script = > engine.CreateScriptSourceFromString(isSubClassCode, > SourceCodeKind.Expression); > bool result = (bool)script.Execute(scope); > > if (result == true) > { > ObjectOperations ops = engine.Operations; > ObjectHandle subClass = scope.GetVariableHandle("C"); // get > back a handle > ObjectHandle instance = ops.Call(subClass, new > ObjectHandle[0]); // invoke the handle to create an instance > mbr = instance.Unwrap() as MbrBase; // now we know we have an > MBR and we can unwrap it to our local side > > ObjectHandle temp = ops.GetMember(instance, "Test_C"); > object log = null; > ops.Call(temp, log); > } > > mbr.DoItVirtually(); > mbr.DoIt(); > Console.ReadKey(); > } > } > > public class MbrBase : MarshalByRefObject > { > public virtual void DoItVirtually() > { > Console.WriteLine("Did it virtually {0}", > AppDomain.CurrentDomain.Id); > } > > public void DoIt() > { > Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); > } > } > > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Aug 12 04:51:13 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 02:51:13 +0000 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: Yep - ScriptScope.InitializeLifetimeService now returns null in 2.6. And doing the same in MbrBase will make it stay alive forever as well. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Wednesday, August 11, 2010 7:25 PM To: Discussion of IronPython Subject: Re: [IronPython] Query regarding Proxy Object lease period I am using IronPython 2.0.When you said ScriptScope is returning null did you mean ScriptScope.InitializeLifetimeService() is returning null. So do you mean to say that overriding "InitializeLifetimeService" in MbrBase is sufficient to keep the hosting API objects alive. On Wed, Aug 11, 2010 at 10:26 PM, Dino Viehland > wrote: What version of IronPython are you using? When I try this against 2.6.1 ScriptScope is "properly" returning null. I would recommend seeing how the lifetime issue stacks up w/ everything returning null. I think long term we need to provide an API that lets you provide the sponsors for hosting API objects but until we do that leasing your own objects may be futile unless there a whole lot of them in comparison to the hosting API objects. I actually haven't done the leasing stuff myself either so I'm not sure I can quickly cook up an example. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Wednesday, August 11, 2010 7:30 AM To: Discussion of IronPython Subject: Re: [IronPython] Query regarding Proxy Object lease period I did override "InitializeLifetimeService" in MbrBase to return null. But in my example the "scope" object dies at first instance, so how would overriding "InitializeLifetimeService" in MbrBase help. Could you please modify my code to illustrate the right usage of ISponsor on the client side. My application will create objects periodically in the appdomain and execute methods implemented in IronPython. These methods may take around 20 minutes to execute. The whole application may run for a day or more. So I need to take this into consideration while implementing the lifetime service. I needed to confirm one thing. Do i need to provide the lease period for all objects created in the Appdomain. As per the code given below do i need to provide the lease period for "code","scope","mbr","script", "ops" etc. Or is it only based on how long I expect the object to be alive. I am new to this concept of Appdomain hence my questions may sound silly. On Tue, Aug 10, 2010 at 10:15 PM, Dino Viehland > wrote: The trick to keeping an object alive isn't to call InitializeLifetimeService yourself but instead to return an appropriate lease. For example if you overrode InitializeLifetimeService in MbrBase to always return null your object will be kept alive forever. That will work fine as long as the app domain isn't living for an extremely long time or that you have a limited number of these MBROs that you're creating in the app domain. We still have this problem to solve in the DLR as well where we're still returning null. I think the correct solution is that we need to use ISponsor's (ClientSPonsor provides an implementation of this) on the client side and then call ILease.Register so the object can call back to your sponser. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Tuesday, August 10, 2010 6:43 AM To: Discussion of IronPython Subject: [IronPython] Query regarding Proxy Object lease period Hi, I posted this last week and I did not get a response.Hence posting it again. I have an application that creates a python engine in a new appdomain. If I do not specify a lease period I see that the objects are disconnected when I leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" to keep the object alive forever but it did not work. The "dlr-spec-hosting" document mentions the following in page 93 under "Current Issues" section : "Currently if you do not use a host for 15 min, it dies, and you lose your data. We've added InitializeLifetimeService on objects to cause them to stay alive forever, but we need to think through the design and the host controls here". Currently I renew the object using "ILease". I do not know if this is the right thing to do. Could you please suggest me the right way to deal with this issue. I have provided the code below for your reference. Thanks, Mustaq using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is this supposed to keep the object alive forever. lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one day. code.Execute(scope); // If the above lease is not mentioned then execution fails on this line after being inactive for 5 minutes. Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustaq2001 at gmail.com Thu Aug 12 05:41:51 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Thu, 12 Aug 2010 09:11:51 +0530 Subject: [IronPython] Query regarding Proxy Object lease period In-Reply-To: References: Message-ID: Yes, IronPython 2.6 returns null whereas 2.0 does not. I will have to use 2.6 going ahead. Thanks for the assistance. I appreciate your quick response. Mustaq On Thu, Aug 12, 2010 at 8:21 AM, Dino Viehland wrote: > Yep ? ScriptScope.InitializeLifetimeService now returns null in 2.6. And > doing the same in MbrBase will make it stay alive forever as well. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Wednesday, August 11, 2010 7:25 PM > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Query regarding Proxy Object lease period > > > > > I am using IronPython 2.0.When you said ScriptScope is returning null did > you mean ScriptScope.InitializeLifetimeService() is returning null. So do > you mean to say that overriding "InitializeLifetimeService" in MbrBase is > sufficient to keep the hosting API objects alive. > > On Wed, Aug 11, 2010 at 10:26 PM, Dino Viehland > wrote: > > What version of IronPython are you using? When I try this against 2.6.1 > ScriptScope is ?properly? returning null. I would recommend seeing how > the lifetime issue stacks up w/ everything returning null. I think long > term we need to provide an API that lets you provide the sponsors for > hosting API objects but until we do that leasing your own objects may be > futile unless there a whole lot of them in comparison to the hosting API > objects. I actually haven?t done the leasing stuff myself either so I?m > not sure I can quickly cook up an example. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Wednesday, August 11, 2010 7:30 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Query regarding Proxy Object lease period > > > > > I did override "InitializeLifetimeService" in MbrBase to return null. But > in my example the "scope" object dies at first instance, so how would > overriding "InitializeLifetimeService" in MbrBase help. Could you please > modify my code to illustrate the right usage of ISponsor on the client side. > > > My application will create objects periodically in the appdomain and > execute methods implemented in IronPython. These methods may take around 20 > minutes to execute. The whole application may run for a day or more. So I > need to take this into consideration while implementing the lifetime > service. > > I needed to confirm one thing. Do i need to provide the lease period for > all objects created in the Appdomain. As per the code given below do i need > to provide the lease period for "code","scope","mbr","script", "ops" etc. > Or is it only based on how long I expect the object to be alive. > > I am new to this concept of Appdomain hence my questions may sound silly. > > On Tue, Aug 10, 2010 at 10:15 PM, Dino Viehland > wrote: > > The trick to keeping an object alive isn?t to call > InitializeLifetimeService yourself but instead to return an appropriate > lease. For example if you overrode InitializeLifetimeService in MbrBase to > always return null your object will be kept alive forever. That will work > fine as long as the app domain isn?t living for an extremely long time or > that you have a limited number of these MBROs that you?re creating in the > app domain. > > > > We still have this problem to solve in the DLR as well where we?re still > returning null. I think the correct solution is that we need to use > ISponsor?s (ClientSPonsor provides an implementation of this) on the client > side and then call ILease.Register so the object can call back to your > sponser. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Tuesday, August 10, 2010 6:43 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Query regarding Proxy Object lease period > > > > > > Hi, > > I posted this last week and I did not get a response.Hence posting it > again. > > I have an application that creates a python engine in a new appdomain. If I > do not specify a lease period I see that the objects are disconnected when I > leave it idle for a period of 5 minutes. I used "InitializeLifetimeService" > to keep the object alive forever but it did not work. The "dlr-spec-hosting" > document mentions the following in page 93 under "Current Issues" section : > "Currently if you do not use a host for 15 min, it dies, and you lose your > data. We've added InitializeLifetimeService on objects to cause them to stay > alive forever, but we need to think through the design and the host controls > here". Currently I renew the object using "ILease". I do not know if this is > the right thing to do. Could you please suggest me the right way to deal > with this issue. I have provided the code below for your reference. > > Thanks, > Mustaq > > using System; > using Microsoft.Scripting; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > using System.Runtime.Remoting; > using System.Runtime.Remoting.Lifetime; > > class Foo > { > public static void Main(string[] args) > { > AppDomain ad = AppDomain.CreateDomain("foo"); > ScriptEngine engine = Python.CreateEngine(ad); > engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); > > ScriptSource code = engine.CreateScriptSourceFromString(@" > import MbrBase > class C(MbrBase): > def Test_C(self, log): > print 0 > a = C() > ", SourceCodeKind.Statements); > > ScriptScope scope = engine.CreateScope(); > ILease lifeTime = (ILease)scope.InitializeLifetimeService(); // Is > this supposed to keep the object alive forever. > > lifeTime.Renew(TimeSpan.FromDays(1)); // Provided a lease for one > day. > code.Execute(scope); // If the above lease is not mentioned then > execution fails on this line after being inactive for 5 minutes. > > Console.WriteLine("Trying to do it... {0}", > AppDomain.CurrentDomain.Id); > MbrBase mbr = (MbrBase)scope.GetVariable("a"); > > string isSubClassCode = String.Format("issubclass({0},{1})", "C", > "MbrBase"); > ScriptSource script = > engine.CreateScriptSourceFromString(isSubClassCode, > SourceCodeKind.Expression); > bool result = (bool)script.Execute(scope); > > if (result == true) > { > ObjectOperations ops = engine.Operations; > ObjectHandle subClass = scope.GetVariableHandle("C"); // get > back a handle > ObjectHandle instance = ops.Call(subClass, new > ObjectHandle[0]); // invoke the handle to create an instance > mbr = instance.Unwrap() as MbrBase; // now we know we have an > MBR and we can unwrap it to our local side > > ObjectHandle temp = ops.GetMember(instance, "Test_C"); > object log = null; > ops.Call(temp, log); > } > > mbr.DoItVirtually(); > mbr.DoIt(); > Console.ReadKey(); > } > } > > public class MbrBase : MarshalByRefObject > { > public virtual void DoItVirtually() > { > Console.WriteLine("Did it virtually {0}", > AppDomain.CurrentDomain.Id); > } > > public void DoIt() > { > Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); > } > } > > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Thu Aug 12 11:36:44 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Thu, 12 Aug 2010 11:36:44 +0200 Subject: [IronPython] IronPython 2.6.2 Message-ID: <4C63C0AC.4060200@bakalari.cz> Hi guys, do you have a release date for IronPython 2.6.2? Thanks. -- -- Lukas From eyvind.axelsen at profdoc.no Thu Aug 12 12:02:55 2010 From: eyvind.axelsen at profdoc.no (Eyvind Axelsen) Date: Thu, 12 Aug 2010 12:02:55 +0200 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: Message-ID: <6A375D8809CD5E4B86F3444358F9A64C2438A4@exchangesrv.profdoc.no> So, no response from the IPY team on this issue? Eyvind. Fra: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] P? vegne av yngipy hernan Sendt: 10. august 2010 05:46 Til: Discussion of IronPython Emne: Re: [IronPython] IronPython / DLR Direction I completely agree with IPy being Microsoft-supported lowers the barrier of entry to enterprise use. I have this problem long time back using Python as the company is a Microsoft shop (mostly). But IronPython being Microsoft pretty much is approved already, no question ask. I am hoping to hear that IronPython will be supported by MS in the next 2 to 5 years or longer ( forever :-) ) if possible. -yngipy On Mon, Aug 9, 2010 at 4:34 PM, Hank Fay wrote: Hi Tony, I have to agree about the barrier being lower if IPy is Microsoft-supported (as all the Iron* languages were announced to be). I had a discussion in January with a market-leader in another country, and their project manager could accept IronPython, barely. His take was: I want to be able to easily hire programmers for customization and/or sourcecode escrow clause necessity. Customization wasn't really an issue (the program uses hooks for customization), as he could hire his bevy of C# developers to do that, but if he had to maintain sourcecode that would be a different story. Having come from a very productive dynamic language (Visual FoxPro) that MS first said could not be ported to .Net, and then when it obviously was possible (in 2005) made no attempt to do so, I'm having a deja vu experience all over again. I'll try not to be as cynical and sarcastic as last time, but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my tongue to prevent shouting out "Middle Management Uber Alles!" (referencing Jimmy's blog post). And so it goes... Hank On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer wrote: On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy wrote: > if [Iron*] die, doesn't that mean MS made the right choice after all? I don't think that's true. .NET isn't just another platform - it's Microsoft's own platform. Some thoughts: Like it or not, and whether it *should* be the case or not, in many organisations (or even teams) if a technology is from Microsoft then it's automatically approved, or at least much easier to approve. The barrier to using Iron* is much lower because they are Microsoft products - this is even more the case with Visual Studio integration. Although Iron* are open-source (which is great, obviously), they aren't typical open-source communities, because of the (somewhat understandable) restriction about accepting code, and the leadership all (AFAIK) being within Microsoft. Microsoft have created this environment (which has worked fairly well so far), and it's not clear how easily that can transition to something that's lead by someone (or ones) outside of Microsoft. Leadership (or at least involvement) within Microsoft opens opportunities for Iron* development to influence .NET. I'm not overly familiar with the details, but I gather than the DLR approach is significantly superior to the IPy 1 CLR approach, and that some of the new dynamic features of C# have benefited from this. It's hard to see how a community IronPython could have developed the DLR, and it seems unlikely that Microsoft would make changes to the CLR to assist it. (Does the latest Microsoft Javascript engine use the DLR (Managed JScript?) - if so, then there's hope, I guess). Projects often need 'angels', especially in the early stages (and I would argue that Iron* are still in early stages). Working on a project of this size takes a lot of resources, and having corporate sponsors makes that a lot easier. Would Python have succeeded if CWI, CNRI, and BeOpen hadn't supported Guido (and others)'s work in the early days? These days the PSF takes this role, but projects need time to build to that sort of size. [Iron]Python (I don't really know much about [Iron]Ruby) is a great language for beginners (students, kids, hobbyists, etc). The Iron variants provide a very smooth path into other .NET development (e.g. C# - which I would say is not at all a great beginner's language). You could argue that Visual Basic provides this functionality as well - I personally find Python much superior to Visual Basic, and since nearly all other BASIC variants are dead now, it doesn't provide an easy road into the .NET world (you have to start there with an unfamiliar language). This last point is the most relevant to me. Over the last few years, NorthTec have switched to using CPython as the first-course programming language, and IronPython as the second-course language. The students *need* to end up with some .NET and Visual Studio experience, because realistically that's what they are most likely to come across in the real world. Many of the students are not capable of starting with C#. If IronPython wasn't a Microsoft project, it would have been considerably more difficult to adopt it - that would likely have meant using Visual Basic (possibly in both courses, because these students struggle learning two languages in their first year). Although this is my unique case, I suspect that there are similar ones, where being a Microsoft product is a deciding factor in whether Iron* can be used (which then impacts the adoption of the language, and therefore whether the language survives). > I think Microsoft is throwing their weight behind JavaScript as their > dynamic language of choice, and I can't really blame them. My hope is that Microsoft realises they have enough weight to throw it in more than once place. (My longer hope, which I know is quite unlikely, is that Windows 8 or 9 includes some version of Iron* out of the box, like OS X includes Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files rather than .exes would significantly help Iron* adoption IMO (and this is something completely impossible for a non-Microsoft Iron*). I know some people must like PowerShell and similar things could be done with it, but it's not the same as having a language with the power and cross-platform nature of Python). Cheers, Tony _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Thu Aug 12 12:21:43 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Thu, 12 Aug 2010 12:21:43 +0200 Subject: [IronPython] Building IronPython from sources In-Reply-To: <299545F35D442642800736DBA0C3AA28033C4CF4@TK5EX14MBXC205.redmond.corp.microsoft.com> References: <4C49EF4B.3060903@bakalari.cz> <299545F35D442642800736DBA0C3AA28033BD014@TK5EX14MBXC205.redmond.corp.microsoft.com> <4C4EF679.1010206@bakalari.cz> <299545F35D442642800736DBA0C3AA28033C4CF4@TK5EX14MBXC205.redmond.corp.microsoft.com> Message-ID: <4C63CB37.5030500@bakalari.cz> This is just confirmation that after installing Silverlight 3 (3.0.50106.0), building works perfectly. However finding Silverlight 3 installation is not easy. Eventually, I found this link: http://silverlight.dlservice.microsoft.com/download/0/D/E/0DEAFE9C-8451-4497-8F8B-DFF82B729818/Silverlight.exe -- -- Lukas On 27.7.2010 17:31, Dave Fugate wrote: > > I'd actually suggest doing this with 2.7 Alpha 1 sources... > > *Building* 2./6.1/ requires a Silverlight /3./x installation as there > were changes to System.Core (e.g., System.Func) between Silverlight > 3.x and Silverlight 4.x. As you've discovered, we implemented some of > this missing System.Core functionality ourselves in 2.6.1 which is > confusing the compiler when there's references to both (4.x) > System.Core and MS.Scripting.Utils. If you can't get your hands on a > Silverlight 3.x installation to fix this, the next easiest route IMO > would be to use 2.7A1 instead. > > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lukas Cenovsky > *Sent:* Tuesday, July 27, 2010 8:09 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Building IronPython from sources > > Thanks. Copying my current Silverlight version 4.0.50524.0 to > 3.0.50106.0 helped and Microsoft.Scripting.dll compiles fine. Now I > get many following errors for Microsoft.Dynamic.dll: > > Error 1 'Func' is an ambiguous reference between > 'System.Func' and > 'Microsoft.Scripting.Utils.Func' > C:\IronPython-2.6.1\Src\Runtime\Microsoft.Dynamic\Interpreter\Instructions\CallInstruction.Generated.cs > 278 70 Microsoft.Dynamic > > How can I tell Visual Studio to use reference from > Microsoft.Scripting.Utils? Thanks. > > -- > -- Lukas > > > On 26.7.2010 18:21, Dave Fugate wrote: > > Hi Lukas, the error message below is because you don't have the > version of Silverlight installed which was used to build IronPython > 2.6.1. For this particular release, I believe it was something like > "%ProgramFiles%\Microsoft Silverlight\3.0.40624.0". You can find out > for sure by examining the "" element in > Src\IronPython\IronPython.csproj. Any ways, there are two workarounds: > > Replace all instances of "3.0.40624.0" throughout all C# project files > with the version of Silverlight you have installed locally > > Copy and rename the version of Silverlight you have installed to > whatever is expected by the C# project files > > Hope that helps, > > Dave > > *From:* users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lukas Cenovsky > *Sent:* Friday, July 23, 2010 12:37 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] Building IronPython from sources > > Hi all, > I have one wish for the next release of IronPython 2.6.2 (hope it is > not too late...) - please make sure it is possible to build IronPython > binaries from sources. I have downloaded > IronPython-2.6.1-Src-Net20SP1.zip > > and I there is no way for me to build Silverlight binaries from it... > > I have opened the solution in VS 2010, solution file was converted to > the new version, I selected 'Silverlight Debug' as a solution > configuration and I received meny errors as below when building > Microsoft.Scripting.dll: > > Error 11 The type 'System.SerializableAttribute' exists in both > 'c:\IronPython-2.6.1\Bin\Silverlight > Debug\Microsoft.Scripting.Core.dll' and > 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll' > C:\IronPython-2.6.1\Src\Runtime\Microsoft.Scripting\ArgumentTypeException.cs > 20 6 Microsoft.Scripting > Error 12 The type or namespace name 'Serializable' could not be > found (are you missing a using directive or an assembly reference?) > C:\IronPython-2.6.1\Src\Runtime\Microsoft.Scripting\ArgumentTypeException.cs > 20 6 Microsoft.Scripting > > My goal was to build debug-able Microsoft.Scripting.Silverlight.dll > because I'm receiving AddReference error which I'd like to inspect. > > -- > -- Lukas > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at schementi.com Thu Aug 12 16:24:29 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Thu, 12 Aug 2010 10:24:29 -0400 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: <6A375D8809CD5E4B86F3444358F9A64C2438A4@exchangesrv.profdoc.no> References: <6A375D8809CD5E4B86F3444358F9A64C2438A4@exchangesrv.profdoc.no> Message-ID: Let's not push Dino or Bill to say anything; This is a enough of a high-profile issue that I'm sure Microsoft's PR firms are working on this. Unfortunately, we'll just have to be patient. ~Jimmy On Thu, Aug 12, 2010 at 6:02 AM, Eyvind Axelsen wrote: > So, no response from the IPY team on this issue? > > > > Eyvind. > > > > *Fra:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *P? vegne av* yngipy hernan > *Sendt:* 10. august 2010 05:46 > *Til:* Discussion of IronPython > *Emne:* Re: [IronPython] IronPython / DLR Direction > > > > I completely agree with IPy being Microsoft-supported lowers the barrier of > entry to enterprise use. I have this problem long time back using Python as > the company is a Microsoft shop (mostly). But IronPython being Microsoft > pretty much is approved already, no question ask. > > > > I am hoping to hear that IronPython will be supported by MS in the next 2 > to 5 years or longer ( forever :-) ) if possible. > > > > -yngipy > > > > On Mon, Aug 9, 2010 at 4:34 PM, Hank Fay wrote: > > Hi Tony, > > > > I have to agree about the barrier being lower if IPy is Microsoft-supported > (as all the Iron* languages were announced to be). I had a discussion in > January with a market-leader in another country, and their project manager > could accept IronPython, barely. His take was: I want to be able to easily > hire programmers for customization and/or sourcecode escrow clause > necessity. Customization wasn't really an issue (the program uses hooks for > customization), as he could hire his bevy of C# developers to do that, but > if he had to maintain sourcecode that would be a different story. > > > > Having come from a very productive dynamic language (Visual FoxPro) that MS > first said could not be ported to .Net, and then when it obviously was > possible (in 2005) made no attempt to do so, I'm having a deja vu experience > all over again. I'll try not to be as cynical and sarcastic as last time, > but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my > tongue to prevent shouting out "Middle Management Uber Alles!" (referencing > Jimmy's blog post). > > > > And so it goes... > > > > Hank > > > > On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer wrote: > > On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy wrote: > > if [Iron*] die, doesn't that mean MS made the right choice after all? > > I don't think that's true. .NET isn't just another platform - it's > Microsoft's own platform. Some thoughts: > > Like it or not, and whether it *should* be the case or not, in many > organisations (or even teams) if a technology is from Microsoft then > it's automatically approved, or at least much easier to approve. The > barrier to using Iron* is much lower because they are Microsoft > products - this is even more the case with Visual Studio integration. > > Although Iron* are open-source (which is great, obviously), they > aren't typical open-source communities, because of the (somewhat > understandable) restriction about accepting code, and the leadership > all (AFAIK) being within Microsoft. Microsoft have created this > environment (which has worked fairly well so far), and it's not clear > how easily that can transition to something that's lead by someone (or > ones) outside of Microsoft. > > Leadership (or at least involvement) within Microsoft opens > opportunities for Iron* development to influence .NET. I'm not overly > familiar with the details, but I gather than the DLR approach is > significantly superior to the IPy 1 CLR approach, and that some of the > new dynamic features of C# have benefited from this. It's hard to see > how a community IronPython could have developed the DLR, and it seems > unlikely that Microsoft would make changes to the CLR to assist it. > (Does the latest Microsoft Javascript engine use the DLR (Managed > JScript?) - if so, then there's hope, I guess). > > Projects often need 'angels', especially in the early stages (and I > would argue that Iron* are still in early stages). Working on a > project of this size takes a lot of resources, and having corporate > sponsors makes that a lot easier. Would Python have succeeded if CWI, > CNRI, and BeOpen hadn't supported Guido (and others)'s work in the > early days? These days the PSF takes this role, but projects need > time to build to that sort of size. > > [Iron]Python (I don't really know much about [Iron]Ruby) is a great > language for beginners (students, kids, hobbyists, etc). The Iron > variants provide a very smooth path into other .NET development (e.g. > C# - which I would say is not at all a great beginner's language). > You could argue that Visual Basic provides this functionality as well > - I personally find Python much superior to Visual Basic, and since > nearly all other BASIC variants are dead now, it doesn't provide an > easy road into the .NET world (you have to start there with an > unfamiliar language). > > This last point is the most relevant to me. Over the last few years, > NorthTec have switched to using CPython as the first-course > programming language, and IronPython as the second-course language. > The students *need* to end up with some .NET and Visual Studio > experience, because realistically that's what they are most likely to > come across in the real world. Many of the students are not capable > of starting with C#. If IronPython wasn't a Microsoft project, it > would have been considerably more difficult to adopt it - that would > likely have meant using Visual Basic (possibly in both courses, > because these students struggle learning two languages in their first > year). Although this is my unique case, I suspect that there are > similar ones, where being a Microsoft product is a deciding factor in > whether Iron* can be used (which then impacts the adoption of the > language, and therefore whether the language survives). > > > > I think Microsoft is throwing their weight behind JavaScript as their > > dynamic language of choice, and I can't really blame them. > > My hope is that Microsoft realises they have enough weight to throw it > in more than once place. > > (My longer hope, which I know is quite unlikely, is that Windows 8 or > 9 includes some version of Iron* out of the box, like OS X includes > Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files > rather than .exes would significantly help Iron* adoption IMO (and > this is something completely impossible for a non-Microsoft Iron*). I > know some people must like PowerShell and similar things could be done > with it, but it's not the same as having a language with the power and > cross-platform nature of Python). > > Cheers, > Tony > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.brostowicz at gmail.com Thu Aug 12 16:34:22 2010 From: cory.brostowicz at gmail.com (Cory Brostowicz) Date: Thu, 12 Aug 2010 09:34:22 -0500 Subject: [IronPython] ScriptScope.SetVariable() performance Message-ID: Hello, I'm trying to get more performance out of my IronPython scripts inside one of my applications, and noticed I'm spending the bulk of my time setting up the ScriptScope prior to execution. My applications translates information coming from a flat file, and I use IronPython to enforce business rules on various records that I pull from my input file. The object that I'm passing to the scope is custom implementation of the ExpandoObject. Am I doing anything out of the ordinary here, or is there a better way to get the performance I'm after? It doesn't seem like setting up the script should performance significantly slower than executing the script itself. Here is an example of the performance results I'm getting. I'm keeping track of various timings for execution time, but the script setup timer is really just stopping and starting a stopwatch before and after each call to ScriptScope.SetVariable()... DUMPING EDIT STATS ------------------ Edit: SetProviderType Count: 70291 Min: 9.927000E-001 Max: 4.922160E+001 Total: 7.656987E+004 Setup: 4.667084E+005 Edit: SetFeeSchedule Count: 70291 Min: 1.572500E+000 Max: 6.547200E+001 Total: 1.067754E+005 Setup: 4.639014E+005 Edit: phDefaultNetworkCode Count: 70291 Min: 1.900000E-002 Max: 2.413129E+002 Total: 1.618541E+003 Setup: 1.161743E+002 Edit: phCloneFieldList Count: 70291 Min: 4.400000E-003 Max: 4.083400E+000 Total: 3.565259E+002 Setup: 1.113712E+002 Edit: phAssignValueToField Count: 70291 Min: 9.700000E-003 Max: 1.777100E+000 Total: 5.765196E+002 Setup: 1.108866E+002 SetProviderType and SetFeeSchedule are both IronPython scripts, the other three are C# edits that I'm passing my ExpandoObject directly to. 4.667 E+005 = almost 8 minutes... 1.108 E+002 = .1 seconds Thanks in advance for any advice you can help me with. -Cory class IronPythonScriptHost : PrimeEditBase { ScriptSource mScriptSource; ScriptEngine mEngine; ScriptScope mScope; public IronPythonScriptHost(string scriptText, string ScriptName, CommandLine mCommandLine, string[] mEditParms, ScriptEngine engine) : base(mCommandLine, mEditParms) { mEditName = ScriptName; mIsScript = true; mEngine = engine; mScriptSource = mEngine.CreateScriptSourceFromString(scriptText, Microsoft.Scripting.SourceCodeKind.File); mScriptSource.Compile(); mScope = mEngine.CreateScope(); } public override void SetupEdit(dynamic editScope) { StartSetupTimer(); mScope.SetVariable("PH", editScope); StopSetupTimer(); } public override void performEdit() { StartExecutionTimer(); try { mScriptSource.Execute(mScope); CleanupEdit(); } catch (Exception ex) { ExceptionOperations ExcOps = mEngine.GetService(); throw new Exception("Exception during execution of " + base.EditName + ". " + ex.Message + "\r\n" + ExcOps.FormatException(ex)); } StopAndRecordExecutionTimer(); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablodalma93 at hotmail.com Thu Aug 12 16:58:08 2010 From: pablodalma93 at hotmail.com (Pablo Dalmazzo) Date: Thu, 12 Aug 2010 11:58:08 -0300 Subject: [IronPython] profiling in IronPython error Message-ID: Hi guys, Im trying to run this test I had in cPython in IronPython 2.6 in asp.net. from profile import * class Prueba(object): @staticmethod def probarvelocidad(): lista = ['a','b','c'] for x in lista: pass run("Prueba.probarvelocidad()","C:\melia") It doesnt work, i get this Mensaje de error del analizador: No module named __main__ Error de c?digo fuente: (Line 454, import __main__ ) L?nea 452: L?nea 453: def run(self, cmd): L?nea 454: import __main__ Any ideas? can I give any more useful information to know which the problem is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at prosysplus.com Thu Aug 12 17:05:14 2010 From: hank at prosysplus.com (Hank Fay) Date: Thu, 12 Aug 2010 11:05:14 -0400 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: <6A375D8809CD5E4B86F3444358F9A64C2438A4@exchangesrv.profdoc.no> Message-ID: Ouch! If PR is the answer, then the wrong question has been asked. And I agree: the people in the middle aren't in a position to comment. Hank PS: When did the relief at getting out of middle hit you? Spokane? S. Dakota? Minnesota? Having been in that kind of position, I know it took a little while for it to sink in when I was out of the middle. I think it was about the 3rd day out on the road for me. On Thu, Aug 12, 2010 at 10:24 AM, Jimmy Schementi wrote: > Let's not push Dino or Bill to say anything; This is a enough of a > high-profile issue that I'm sure Microsoft's PR firms are working on this. > Unfortunately, we'll just have to be patient. > > ~Jimmy > > > > On Thu, Aug 12, 2010 at 6:02 AM, Eyvind Axelsen > wrote: > >> So, no response from the IPY team on this issue? >> >> >> >> Eyvind. >> >> >> >> *Fra:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *P? vegne av* yngipy hernan >> *Sendt:* 10. august 2010 05:46 >> *Til:* Discussion of IronPython >> *Emne:* Re: [IronPython] IronPython / DLR Direction >> >> >> >> I completely agree with IPy being Microsoft-supported lowers the barrier >> of entry to enterprise use. I have this problem long time back using Python >> as the company is a Microsoft shop (mostly). But IronPython being Microsoft >> pretty much is approved already, no question ask. >> >> >> >> I am hoping to hear that IronPython will be supported by MS in the next 2 >> to 5 years or longer ( forever :-) ) if possible. >> >> >> >> -yngipy >> >> >> >> On Mon, Aug 9, 2010 at 4:34 PM, Hank Fay wrote: >> >> Hi Tony, >> >> >> >> I have to agree about the barrier being lower if IPy is >> Microsoft-supported (as all the Iron* languages were announced to be). I >> had a discussion in January with a market-leader in another country, and >> their project manager could accept IronPython, barely. His take was: I want >> to be able to easily hire programmers for customization and/or sourcecode >> escrow clause necessity. Customization wasn't really an issue (the program >> uses hooks for customization), as he could hire his bevy of C# developers to >> do that, but if he had to maintain sourcecode that would be a different >> story. >> >> >> >> Having come from a very productive dynamic language (Visual FoxPro) that >> MS first said could not be ported to .Net, and then when it obviously was >> possible (in 2005) made no attempt to do so, I'm having a deja vu experience >> all over again. I'll try not to be as cynical and sarcastic as last time, >> but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my >> tongue to prevent shouting out "Middle Management Uber Alles!" (referencing >> Jimmy's blog post). >> >> >> >> And so it goes... >> >> >> >> Hank >> >> >> >> On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer wrote: >> >> On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy wrote: >> > if [Iron*] die, doesn't that mean MS made the right choice after all? >> >> I don't think that's true. .NET isn't just another platform - it's >> Microsoft's own platform. Some thoughts: >> >> Like it or not, and whether it *should* be the case or not, in many >> organisations (or even teams) if a technology is from Microsoft then >> it's automatically approved, or at least much easier to approve. The >> barrier to using Iron* is much lower because they are Microsoft >> products - this is even more the case with Visual Studio integration. >> >> Although Iron* are open-source (which is great, obviously), they >> aren't typical open-source communities, because of the (somewhat >> understandable) restriction about accepting code, and the leadership >> all (AFAIK) being within Microsoft. Microsoft have created this >> environment (which has worked fairly well so far), and it's not clear >> how easily that can transition to something that's lead by someone (or >> ones) outside of Microsoft. >> >> Leadership (or at least involvement) within Microsoft opens >> opportunities for Iron* development to influence .NET. I'm not overly >> familiar with the details, but I gather than the DLR approach is >> significantly superior to the IPy 1 CLR approach, and that some of the >> new dynamic features of C# have benefited from this. It's hard to see >> how a community IronPython could have developed the DLR, and it seems >> unlikely that Microsoft would make changes to the CLR to assist it. >> (Does the latest Microsoft Javascript engine use the DLR (Managed >> JScript?) - if so, then there's hope, I guess). >> >> Projects often need 'angels', especially in the early stages (and I >> would argue that Iron* are still in early stages). Working on a >> project of this size takes a lot of resources, and having corporate >> sponsors makes that a lot easier. Would Python have succeeded if CWI, >> CNRI, and BeOpen hadn't supported Guido (and others)'s work in the >> early days? These days the PSF takes this role, but projects need >> time to build to that sort of size. >> >> [Iron]Python (I don't really know much about [Iron]Ruby) is a great >> language for beginners (students, kids, hobbyists, etc). The Iron >> variants provide a very smooth path into other .NET development (e.g. >> C# - which I would say is not at all a great beginner's language). >> You could argue that Visual Basic provides this functionality as well >> - I personally find Python much superior to Visual Basic, and since >> nearly all other BASIC variants are dead now, it doesn't provide an >> easy road into the .NET world (you have to start there with an >> unfamiliar language). >> >> This last point is the most relevant to me. Over the last few years, >> NorthTec have switched to using CPython as the first-course >> programming language, and IronPython as the second-course language. >> The students *need* to end up with some .NET and Visual Studio >> experience, because realistically that's what they are most likely to >> come across in the real world. Many of the students are not capable >> of starting with C#. If IronPython wasn't a Microsoft project, it >> would have been considerably more difficult to adopt it - that would >> likely have meant using Visual Basic (possibly in both courses, >> because these students struggle learning two languages in their first >> year). Although this is my unique case, I suspect that there are >> similar ones, where being a Microsoft product is a deciding factor in >> whether Iron* can be used (which then impacts the adoption of the >> language, and therefore whether the language survives). >> >> >> > I think Microsoft is throwing their weight behind JavaScript as their >> > dynamic language of choice, and I can't really blame them. >> >> My hope is that Microsoft realises they have enough weight to throw it >> in more than once place. >> >> (My longer hope, which I know is quite unlikely, is that Windows 8 or >> 9 includes some version of Iron* out of the box, like OS X includes >> Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files >> rather than .exes would significantly help Iron* adoption IMO (and >> this is something completely impossible for a non-Microsoft Iron*). I >> know some people must like PowerShell and similar things could be done >> with it, but it's not the same as having a language with the power and >> cross-platform nature of Python). >> >> Cheers, >> Tony >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Thu Aug 12 17:34:00 2010 From: dfugate at microsoft.com (Dave Fugate) Date: Thu, 12 Aug 2010 15:34:00 +0000 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: References: <6A375D8809CD5E4B86F3444358F9A64C2438A4@exchangesrv.profdoc.no> Message-ID: <299545F35D442642800736DBA0C3AA280343156A@TK5EX14MBXC201.redmond.corp.microsoft.com> All the team can say at this point is that there's an official comment from Microsoft on Mary-Jo Foley's blog - see "Update (August 10)" on http://www.zdnet.com/blog/microsoft/whats-next-for-microsofts-ironruby/7034?tag=mantle_skin;content. Dave From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Hank Fay Sent: Thursday, August 12, 2010 8:05 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython / DLR Direction Ouch! If PR is the answer, then the wrong question has been asked. And I agree: the people in the middle aren't in a position to comment. Hank PS: When did the relief at getting out of middle hit you? Spokane? S. Dakota? Minnesota? Having been in that kind of position, I know it took a little while for it to sink in when I was out of the middle. I think it was about the 3rd day out on the road for me. On Thu, Aug 12, 2010 at 10:24 AM, Jimmy Schementi > wrote: Let's not push Dino or Bill to say anything; This is a enough of a high-profile issue that I'm sure Microsoft's PR firms are working on this. Unfortunately, we'll just have to be patient. ~Jimmy On Thu, Aug 12, 2010 at 6:02 AM, Eyvind Axelsen > wrote: So, no response from the IPY team on this issue? Eyvind. Fra: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] P? vegne av yngipy hernan Sendt: 10. august 2010 05:46 Til: Discussion of IronPython Emne: Re: [IronPython] IronPython / DLR Direction I completely agree with IPy being Microsoft-supported lowers the barrier of entry to enterprise use. I have this problem long time back using Python as the company is a Microsoft shop (mostly). But IronPython being Microsoft pretty much is approved already, no question ask. I am hoping to hear that IronPython will be supported by MS in the next 2 to 5 years or longer ( forever :-) ) if possible. -yngipy On Mon, Aug 9, 2010 at 4:34 PM, Hank Fay > wrote: Hi Tony, I have to agree about the barrier being lower if IPy is Microsoft-supported (as all the Iron* languages were announced to be). I had a discussion in January with a market-leader in another country, and their project manager could accept IronPython, barely. His take was: I want to be able to easily hire programmers for customization and/or sourcecode escrow clause necessity. Customization wasn't really an issue (the program uses hooks for customization), as he could hire his bevy of C# developers to do that, but if he had to maintain sourcecode that would be a different story. Having come from a very productive dynamic language (Visual FoxPro) that MS first said could not be ported to .Net, and then when it obviously was possible (in 2005) made no attempt to do so, I'm having a deja vu experience all over again. I'll try not to be as cynical and sarcastic as last time, but I'm having to hold my arm down (shades of Dr. Strangelove) and hold my tongue to prevent shouting out "Middle Management Uber Alles!" (referencing Jimmy's blog post). And so it goes... Hank On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer > wrote: On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy > wrote: > if [Iron*] die, doesn't that mean MS made the right choice after all? I don't think that's true. .NET isn't just another platform - it's Microsoft's own platform. Some thoughts: Like it or not, and whether it *should* be the case or not, in many organisations (or even teams) if a technology is from Microsoft then it's automatically approved, or at least much easier to approve. The barrier to using Iron* is much lower because they are Microsoft products - this is even more the case with Visual Studio integration. Although Iron* are open-source (which is great, obviously), they aren't typical open-source communities, because of the (somewhat understandable) restriction about accepting code, and the leadership all (AFAIK) being within Microsoft. Microsoft have created this environment (which has worked fairly well so far), and it's not clear how easily that can transition to something that's lead by someone (or ones) outside of Microsoft. Leadership (or at least involvement) within Microsoft opens opportunities for Iron* development to influence .NET. I'm not overly familiar with the details, but I gather than the DLR approach is significantly superior to the IPy 1 CLR approach, and that some of the new dynamic features of C# have benefited from this. It's hard to see how a community IronPython could have developed the DLR, and it seems unlikely that Microsoft would make changes to the CLR to assist it. (Does the latest Microsoft Javascript engine use the DLR (Managed JScript?) - if so, then there's hope, I guess). Projects often need 'angels', especially in the early stages (and I would argue that Iron* are still in early stages). Working on a project of this size takes a lot of resources, and having corporate sponsors makes that a lot easier. Would Python have succeeded if CWI, CNRI, and BeOpen hadn't supported Guido (and others)'s work in the early days? These days the PSF takes this role, but projects need time to build to that sort of size. [Iron]Python (I don't really know much about [Iron]Ruby) is a great language for beginners (students, kids, hobbyists, etc). The Iron variants provide a very smooth path into other .NET development (e.g. C# - which I would say is not at all a great beginner's language). You could argue that Visual Basic provides this functionality as well - I personally find Python much superior to Visual Basic, and since nearly all other BASIC variants are dead now, it doesn't provide an easy road into the .NET world (you have to start there with an unfamiliar language). This last point is the most relevant to me. Over the last few years, NorthTec have switched to using CPython as the first-course programming language, and IronPython as the second-course language. The students *need* to end up with some .NET and Visual Studio experience, because realistically that's what they are most likely to come across in the real world. Many of the students are not capable of starting with C#. If IronPython wasn't a Microsoft project, it would have been considerably more difficult to adopt it - that would likely have meant using Visual Basic (possibly in both courses, because these students struggle learning two languages in their first year). Although this is my unique case, I suspect that there are similar ones, where being a Microsoft product is a deciding factor in whether Iron* can be used (which then impacts the adoption of the language, and therefore whether the language survives). > I think Microsoft is throwing their weight behind JavaScript as their > dynamic language of choice, and I can't really blame them. My hope is that Microsoft realises they have enough weight to throw it in more than once place. (My longer hope, which I know is quite unlikely, is that Windows 8 or 9 includes some version of Iron* out of the box, like OS X includes Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files rather than .exes would significantly help Iron* adoption IMO (and this is something completely impossible for a non-Microsoft Iron*). I know some people must like PowerShell and similar things could be done with it, but it's not the same as having a language with the power and cross-platform nature of Python). Cheers, Tony _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Thu Aug 12 17:40:05 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Thu, 12 Aug 2010 08:40:05 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75397. MODIFIED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Exceptions/IndentationException.cs $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_exceptions.py $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonToolsPackage.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Options/PythonOptionsControl.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Options/PythonOptionsControl.Designer.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Options/PythonOptionsControl.resx $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Options/PythonOptionsPage.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Repl/RemotePythonVsEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore/Repl/RemotePythonEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio/CommonPackage.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio/Project/CommonReferenceContainerNode.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio/Project/CommonSearchPathContainerNode.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio/Repl/VsReplWindow.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/VisualStudio/Project/Automation/OANavigableProjectItems.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/RemoteScriptFactory.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/AutoIndent.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/IReplWindow.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/ReplWindow.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/Commands/CancelExecutionCommand.cs From dinov at microsoft.com Thu Aug 12 18:42:14 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 16:42:14 +0000 Subject: [IronPython] ScriptScope.SetVariable() performance In-Reply-To: References: Message-ID: I'd suggest doing mScope.PH = editScope. That will create a rule which will get cached and will generally run faster than passing the string directly. The only other thing I can think of is maybe there's something odd w/ rule being produced because "editScope" is a dynamic object in SetupEdit so "mScope.SetVariable("PH", editScope);" ends up dispatching dynamically. If you did "mScope.SetVariable("PH", (object)editScope);" it would dispatch statically. If neither of those solutions helps I can see if I can look deeper and see if I can repro it. There were some issues w/ IronPython 2.6 where this was really slow but they should have been fixed w/ 2.6.1. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cory Brostowicz Sent: Thursday, August 12, 2010 7:34 AM To: users at lists.ironpython.com Subject: [IronPython] ScriptScope.SetVariable() performance Hello, I'm trying to get more performance out of my IronPython scripts inside one of my applications, and noticed I'm spending the bulk of my time setting up the ScriptScope prior to execution. My applications translates information coming from a flat file, and I use IronPython to enforce business rules on various records that I pull from my input file. The object that I'm passing to the scope is custom implementation of the ExpandoObject. Am I doing anything out of the ordinary here, or is there a better way to get the performance I'm after? It doesn't seem like setting up the script should performance significantly slower than executing the script itself. Here is an example of the performance results I'm getting. I'm keeping track of various timings for execution time, but the script setup timer is really just stopping and starting a stopwatch before and after each call to ScriptScope.SetVariable()... DUMPING EDIT STATS ------------------ Edit: SetProviderType Count: 70291 Min: 9.927000E-001 Max: 4.922160E+001 Total: 7.656987E+004 Setup: 4.667084E+005 Edit: SetFeeSchedule Count: 70291 Min: 1.572500E+000 Max: 6.547200E+001 Total: 1.067754E+005 Setup: 4.639014E+005 Edit: phDefaultNetworkCode Count: 70291 Min: 1.900000E-002 Max: 2.413129E+002 Total: 1.618541E+003 Setup: 1.161743E+002 Edit: phCloneFieldList Count: 70291 Min: 4.400000E-003 Max: 4.083400E+000 Total: 3.565259E+002 Setup: 1.113712E+002 Edit: phAssignValueToField Count: 70291 Min: 9.700000E-003 Max: 1.777100E+000 Total: 5.765196E+002 Setup: 1.108866E+002 SetProviderType and SetFeeSchedule are both IronPython scripts, the other three are C# edits that I'm passing my ExpandoObject directly to. 4.667 E+005 = almost 8 minutes... 1.108 E+002 = .1 seconds Thanks in advance for any advice you can help me with. -Cory class IronPythonScriptHost : PrimeEditBase { ScriptSource mScriptSource; ScriptEngine mEngine; ScriptScope mScope; public IronPythonScriptHost(string scriptText, string ScriptName, CommandLine mCommandLine, string[] mEditParms, ScriptEngine engine) : base(mCommandLine, mEditParms) { mEditName = ScriptName; mIsScript = true; mEngine = engine; mScriptSource = mEngine.CreateScriptSourceFromString(scriptText, Microsoft.Scripting.SourceCodeKind.File); mScriptSource.Compile(); mScope = mEngine.CreateScope(); } public override void SetupEdit(dynamic editScope) { StartSetupTimer(); mScope.SetVariable("PH", editScope); StopSetupTimer(); } public override void performEdit() { StartExecutionTimer(); try { mScriptSource.Execute(mScope); CleanupEdit(); } catch (Exception ex) { ExceptionOperations ExcOps = mEngine.GetService(); throw new Exception("Exception during execution of " + base.EditName + ". " + ex.Message + "\r\n" + ExcOps.FormatException(ex)); } StopAndRecordExecutionTimer(); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Thu Aug 12 18:56:14 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Thu, 12 Aug 2010 18:56:14 +0200 Subject: [IronPython] IronPython / DLR Direction In-Reply-To: <299545F35D442642800736DBA0C3AA280343156A@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <6A375D8809CD5E4B86F3444358F9A64C2438A4@exchangesrv.profdoc.no> <299545F35D442642800736DBA0C3AA280343156A@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-ID: <4C6427AE.6070404@bakalari.cz> Thank you for the info. -- -- Lukas On 12.8.2010 17:34, Dave Fugate wrote: > > All the team can say at this point is that there's an official comment > from Microsoft on Mary-Jo Foley's blog -- see "Update (August 10)" on > http://www.zdnet.com/blog/microsoft/whats-next-for-microsofts-ironruby/7034?tag=mantle_skin;content. > > > Dave > > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Hank Fay > *Sent:* Thursday, August 12, 2010 8:05 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] IronPython / DLR Direction > > Ouch! If PR is the answer, then the wrong question has been asked. > > And I agree: the people in the middle aren't in a position to comment. > > Hank > > PS: When did the relief at getting out of middle hit you? Spokane? > S. Dakota? Minnesota? Having been in that kind of position, I > know it took a little while for it to sink in when I was out of the > middle. I think it was about the 3rd day out on the road for me. > > On Thu, Aug 12, 2010 at 10:24 AM, Jimmy Schementi > wrote: > > Let's not push Dino or Bill to say anything; This is a enough of a > high-profile issue that I'm sure Microsoft's PR firms are working on > this. Unfortunately, we'll just have to be patient. > > ~Jimmy > > > > On Thu, Aug 12, 2010 at 6:02 AM, Eyvind Axelsen > > wrote: > > So, no response from the IPY team on this issue? > > Eyvind. > > *Fra:* users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com > ] *P? vegne av* yngipy hernan > *Sendt:* 10. august 2010 05:46 > *Til:* Discussion of IronPython > *Emne:* Re: [IronPython] IronPython / DLR Direction > > I completely agree with IPy being Microsoft-supported lowers the > barrier of entry to enterprise use. I have this problem long time back > using Python as the company is a Microsoft shop (mostly). But > IronPython being Microsoft pretty much is approved already, no > question ask. > > I am hoping to hear that IronPython will be supported by MS in the > next 2 to 5 years or longer ( forever :-) ) if possible. > > -yngipy > > On Mon, Aug 9, 2010 at 4:34 PM, Hank Fay > wrote: > > Hi Tony, > > I have to agree about the barrier being lower if IPy is > Microsoft-supported (as all the Iron* languages were announced to be). > I had a discussion in January with a market-leader in another > country, and their project manager could accept IronPython, barely. > His take was: I want to be able to easily hire programmers for > customization and/or sourcecode escrow clause necessity. > Customization wasn't really an issue (the program uses hooks for > customization), as he could hire his bevy of C# developers to do that, > but if he had to maintain sourcecode that would be a different story. > > Having come from a very productive dynamic language (Visual FoxPro) > that MS first said could not be ported to .Net, and then when it > obviously was possible (in 2005) made no attempt to do so, I'm having > a deja vu experience all over again. I'll try not to be as cynical > and sarcastic as last time, but I'm having to hold my arm down (shades > of Dr. Strangelove) and hold my tongue to prevent shouting out "Middle > Management Uber Alles!" (referencing Jimmy's blog post). > > And so it goes... > > Hank > > On Mon, Aug 9, 2010 at 12:43 AM, Tony Meyer > wrote: > > On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy > wrote: > > if [Iron*] die, doesn't that mean MS made the right choice after all? > > I don't think that's true. .NET isn't just another platform - it's > Microsoft's own platform. Some thoughts: > > Like it or not, and whether it *should* be the case or not, in many > organisations (or even teams) if a technology is from Microsoft then > it's automatically approved, or at least much easier to approve. The > barrier to using Iron* is much lower because they are Microsoft > products - this is even more the case with Visual Studio integration. > > Although Iron* are open-source (which is great, obviously), they > aren't typical open-source communities, because of the (somewhat > understandable) restriction about accepting code, and the leadership > all (AFAIK) being within Microsoft. Microsoft have created this > environment (which has worked fairly well so far), and it's not clear > how easily that can transition to something that's lead by someone (or > ones) outside of Microsoft. > > Leadership (or at least involvement) within Microsoft opens > opportunities for Iron* development to influence .NET. I'm not overly > familiar with the details, but I gather than the DLR approach is > significantly superior to the IPy 1 CLR approach, and that some of the > new dynamic features of C# have benefited from this. It's hard to see > how a community IronPython could have developed the DLR, and it seems > unlikely that Microsoft would make changes to the CLR to assist it. > (Does the latest Microsoft Javascript engine use the DLR (Managed > JScript?) - if so, then there's hope, I guess). > > Projects often need 'angels', especially in the early stages (and I > would argue that Iron* are still in early stages). Working on a > project of this size takes a lot of resources, and having corporate > sponsors makes that a lot easier. Would Python have succeeded if CWI, > CNRI, and BeOpen hadn't supported Guido (and others)'s work in the > early days? These days the PSF takes this role, but projects need > time to build to that sort of size. > > [Iron]Python (I don't really know much about [Iron]Ruby) is a great > language for beginners (students, kids, hobbyists, etc). The Iron > variants provide a very smooth path into other .NET development (e.g. > C# - which I would say is not at all a great beginner's language). > You could argue that Visual Basic provides this functionality as well > - I personally find Python much superior to Visual Basic, and since > nearly all other BASIC variants are dead now, it doesn't provide an > easy road into the .NET world (you have to start there with an > unfamiliar language). > > This last point is the most relevant to me. Over the last few years, > NorthTec have switched to using CPython as the first-course > programming language, and IronPython as the second-course language. > The students *need* to end up with some .NET and Visual Studio > experience, because realistically that's what they are most likely to > come across in the real world. Many of the students are not capable > of starting with C#. If IronPython wasn't a Microsoft project, it > would have been considerably more difficult to adopt it - that would > likely have meant using Visual Basic (possibly in both courses, > because these students struggle learning two languages in their first > year). Although this is my unique case, I suspect that there are > similar ones, where being a Microsoft product is a deciding factor in > whether Iron* can be used (which then impacts the adoption of the > language, and therefore whether the language survives). > > > > I think Microsoft is throwing their weight behind JavaScript as their > > dynamic language of choice, and I can't really blame them. > > My hope is that Microsoft realises they have enough weight to throw it > in more than once place. > > (My longer hope, which I know is quite unlikely, is that Windows 8 or > 9 includes some version of Iron* out of the box, like OS X includes > Python/Perl/PHP/Ruby/etc. Being able to distribute .py[co] files > rather than .exes would significantly help Iron* adoption IMO (and > this is something completely impossible for a non-Microsoft Iron*). I > know some people must like PowerShell and similar things could be done > with it, but it's not the same as having a language with the power and > cross-platform nature of Python). > > Cheers, > Tony > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.brostowicz at gmail.com Thu Aug 12 19:10:40 2010 From: cory.brostowicz at gmail.com (Cory Brostowicz) Date: Thu, 12 Aug 2010 12:10:40 -0500 Subject: [IronPython] ScriptScope.SetVariable() performance In-Reply-To: References: Message-ID: I'm not sure what you mean by "mScope.PH = editScope". mScope = ScriptScope and doesn't allow dynamic properties. On the other hand, thanks for the suggestion with the object cast. That gave brought my setup performance up to par with the native C# edits! Edit: SetProviderType Count: 70291 Min: 9.866000E-001 Max: 5.393440E+001 Total: 6.684688E+004 Setup: 1.904770E+002 Edit: SetFeeSchedule Count: 70291 Min: 1.229300E+000 Max: 6.506160E+001 Total: 9.587090E+004 Setup: 1.747695E+002 Edit: phDefaultNetworkCode Count: 70291 Min: 9.700000E-003 Max: 2.347088E+002 Total: 1.154772E+003 Setup: 1.156382E+002 Edit: phCloneFieldList Count: 70291 Min: 3.200000E-003 Max: 4.007700E+000 Total: 2.727729E+002 Setup: 1.137180E+002 Edit: phAssignValueToField Count: 70291 Min: 4.400000E-003 Max: 1.205800E+000 Total: 4.475063E+002 Setup: 1.152221E+002 On Thu, Aug 12, 2010 at 11:42 AM, Dino Viehland wrote: > I?d suggest doing mScope.PH = editScope. That will create a rule which > will get cached and will generally run faster than passing the string > directly. > > > > The only other thing I can think of is maybe there?s something odd w/ rule > being produced because ?editScope? is a dynamic object in SetupEdit so ?mScope.SetVariable("PH", > editScope);? ends up dispatching dynamically. If you did ?mScope.SetVariable("PH", > (object)editScope);? it would dispatch statically. > > > > If neither of those solutions helps I can see if I can look deeper and see > if I can repro it. There were some issues w/ IronPython 2.6 where this was > really slow but they should have been fixed w/ 2.6.1. > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Cory Brostowicz > *Sent:* Thursday, August 12, 2010 7:34 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] ScriptScope.SetVariable() performance > > > > Hello, > > > > I'm trying to get more performance out of my IronPython scripts inside one > of my applications, and noticed I'm spending the bulk of my time setting up > the ScriptScope prior to execution. My applications translates information > coming from a flat file, and I use IronPython to enforce business rules on > various records that I pull from my input file. The object that I'm passing > to the scope is custom implementation of the ExpandoObject. > > > > Am I doing anything out of the ordinary here, or is there a better way to > get the performance I'm after? It doesn't seem like setting up the script > should performance significantly slower than executing the script itself. > > > Here is an example of the performance results I'm getting. I'm keeping > track of various timings for execution time, but the script setup timer is > really just stopping and starting a stopwatch before and after each call to > ScriptScope.SetVariable()... > > > > > > DUMPING EDIT STATS > > ------------------ > > > > Edit: SetProviderType Count: 70291 Min: 9.927000E-001 Max: > 4.922160E+001 Total: 7.656987E+004 Setup: 4.667084E+005 > > Edit: SetFeeSchedule Count: 70291 Min: 1.572500E+000 Max: > 6.547200E+001 Total: 1.067754E+005 Setup: 4.639014E+005 > > Edit: phDefaultNetworkCode Count: 70291 Min: 1.900000E-002 Max: > 2.413129E+002 Total: 1.618541E+003 Setup: 1.161743E+002 > > Edit: phCloneFieldList Count: 70291 Min: 4.400000E-003 Max: > 4.083400E+000 Total: 3.565259E+002 Setup: 1.113712E+002 > > Edit: phAssignValueToField Count: 70291 Min: 9.700000E-003 Max: > 1.777100E+000 Total: 5.765196E+002 Setup: 1.108866E+002 > > > > > > SetProviderType and SetFeeSchedule are both IronPython scripts, the other > three are C# edits that I'm passing my ExpandoObject directly to. > > > > 4.667 E+005 = almost 8 minutes... > > 1.108 E+002 = .1 seconds > > > > > > Thanks in advance for any advice you can help me with. > > > > -Cory > > > > class IronPythonScriptHost : PrimeEditBase { > > ScriptSource mScriptSource; > > ScriptEngine mEngine; > > ScriptScope mScope; > > > > public IronPythonScriptHost(string scriptText, > string ScriptName, CommandLine mCommandLine, string[] mEditParms, > ScriptEngine engine) > > : base(mCommandLine, mEditParms) { > > mEditName = ScriptName; > > mIsScript = true; > > mEngine = engine; > > mScriptSource = > mEngine.CreateScriptSourceFromString(scriptText, > Microsoft.Scripting.SourceCodeKind.File); > > mScriptSource.Compile(); > > mScope = mEngine.CreateScope(); > > } > > public override void SetupEdit(dynamic editScope) { > > > > StartSetupTimer(); > > mScope.SetVariable("PH", editScope); > > StopSetupTimer(); > > } > > > > public override void performEdit() { > > StartExecutionTimer(); > > try { > > > mScriptSource.Execute(mScope); > > CleanupEdit(); > > } catch (Exception ex) { > > ExceptionOperations ExcOps = > mEngine.GetService(); > > throw new > Exception("Exception during execution of " + base.EditName + ". " + > ex.Message + "\r\n" + ExcOps.FormatException(ex)); > > } > > StopAndRecordExecutionTimer(); > > } > > } > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Aug 12 19:24:59 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 17:24:59 +0000 Subject: [IronPython] ScriptScope.SetVariable() performance In-Reply-To: References: Message-ID: Oh, yeah, objects aren't dynamic unless they're typed to dynamic :) I guess it needs to be: ((dynamic)mScope).PH = editScope; From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cory Brostowicz Sent: Thursday, August 12, 2010 10:11 AM To: Discussion of IronPython Subject: Re: [IronPython] ScriptScope.SetVariable() performance I'm not sure what you mean by "mScope.PH = editScope". mScope = ScriptScope and doesn't allow dynamic properties. On the other hand, thanks for the suggestion with the object cast. That gave brought my setup performance up to par with the native C# edits! Edit: SetProviderType Count: 70291 Min: 9.866000E-001 Max: 5.393440E+001 Total: 6.684688E+004 Setup: 1.904770E+002 Edit: SetFeeSchedule Count: 70291 Min: 1.229300E+000 Max: 6.506160E+001 Total: 9.587090E+004 Setup: 1.747695E+002 Edit: phDefaultNetworkCode Count: 70291 Min: 9.700000E-003 Max: 2.347088E+002 Total: 1.154772E+003 Setup: 1.156382E+002 Edit: phCloneFieldList Count: 70291 Min: 3.200000E-003 Max: 4.007700E+000 Total: 2.727729E+002 Setup: 1.137180E+002 Edit: phAssignValueToField Count: 70291 Min: 4.400000E-003 Max: 1.205800E+000 Total: 4.475063E+002 Setup: 1.152221E+002 On Thu, Aug 12, 2010 at 11:42 AM, Dino Viehland > wrote: I'd suggest doing mScope.PH = editScope. That will create a rule which will get cached and will generally run faster than passing the string directly. The only other thing I can think of is maybe there's something odd w/ rule being produced because "editScope" is a dynamic object in SetupEdit so "mScope.SetVariable("PH", editScope);" ends up dispatching dynamically. If you did "mScope.SetVariable("PH", (object)editScope);" it would dispatch statically. If neither of those solutions helps I can see if I can look deeper and see if I can repro it. There were some issues w/ IronPython 2.6 where this was really slow but they should have been fixed w/ 2.6.1. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cory Brostowicz Sent: Thursday, August 12, 2010 7:34 AM To: users at lists.ironpython.com Subject: [IronPython] ScriptScope.SetVariable() performance Hello, I'm trying to get more performance out of my IronPython scripts inside one of my applications, and noticed I'm spending the bulk of my time setting up the ScriptScope prior to execution. My applications translates information coming from a flat file, and I use IronPython to enforce business rules on various records that I pull from my input file. The object that I'm passing to the scope is custom implementation of the ExpandoObject. Am I doing anything out of the ordinary here, or is there a better way to get the performance I'm after? It doesn't seem like setting up the script should performance significantly slower than executing the script itself. Here is an example of the performance results I'm getting. I'm keeping track of various timings for execution time, but the script setup timer is really just stopping and starting a stopwatch before and after each call to ScriptScope.SetVariable()... DUMPING EDIT STATS ------------------ Edit: SetProviderType Count: 70291 Min: 9.927000E-001 Max: 4.922160E+001 Total: 7.656987E+004 Setup: 4.667084E+005 Edit: SetFeeSchedule Count: 70291 Min: 1.572500E+000 Max: 6.547200E+001 Total: 1.067754E+005 Setup: 4.639014E+005 Edit: phDefaultNetworkCode Count: 70291 Min: 1.900000E-002 Max: 2.413129E+002 Total: 1.618541E+003 Setup: 1.161743E+002 Edit: phCloneFieldList Count: 70291 Min: 4.400000E-003 Max: 4.083400E+000 Total: 3.565259E+002 Setup: 1.113712E+002 Edit: phAssignValueToField Count: 70291 Min: 9.700000E-003 Max: 1.777100E+000 Total: 5.765196E+002 Setup: 1.108866E+002 SetProviderType and SetFeeSchedule are both IronPython scripts, the other three are C# edits that I'm passing my ExpandoObject directly to. 4.667 E+005 = almost 8 minutes... 1.108 E+002 = .1 seconds Thanks in advance for any advice you can help me with. -Cory class IronPythonScriptHost : PrimeEditBase { ScriptSource mScriptSource; ScriptEngine mEngine; ScriptScope mScope; public IronPythonScriptHost(string scriptText, string ScriptName, CommandLine mCommandLine, string[] mEditParms, ScriptEngine engine) : base(mCommandLine, mEditParms) { mEditName = ScriptName; mIsScript = true; mEngine = engine; mScriptSource = mEngine.CreateScriptSourceFromString(scriptText, Microsoft.Scripting.SourceCodeKind.File); mScriptSource.Compile(); mScope = mEngine.CreateScope(); } public override void SetupEdit(dynamic editScope) { StartSetupTimer(); mScope.SetVariable("PH", editScope); StopSetupTimer(); } public override void performEdit() { StartExecutionTimer(); try { mScriptSource.Execute(mScope); CleanupEdit(); } catch (Exception ex) { ExceptionOperations ExcOps = mEngine.GetService(); throw new Exception("Exception during execution of " + base.EditName + ". " + ex.Message + "\r\n" + ExcOps.FormatException(ex)); } StopAndRecordExecutionTimer(); } } _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.brostowicz at gmail.com Thu Aug 12 21:38:45 2010 From: cory.brostowicz at gmail.com (Cory Brostowicz) Date: Thu, 12 Aug 2010 14:38:45 -0500 Subject: [IronPython] ScriptScope.SetVariable() performance In-Reply-To: References: Message-ID: FYI - This method worked a ton faster than my original design, however casting the dynamic variable to an object is almost twice as fast as this approach. Thanks again for the help, that helped a ton! -Cory On Thu, Aug 12, 2010 at 12:24 PM, Dino Viehland wrote: > Oh, yeah, objects aren?t dynamic unless they?re typed to dynamic J I > guess it needs to be: > > ((dynamic)mScope).PH = editScope; > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Cory Brostowicz > *Sent:* Thursday, August 12, 2010 10:11 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] ScriptScope.SetVariable() performance > > > > I'm not sure what you mean by "mScope.PH = editScope". mScope = > ScriptScope and doesn't allow dynamic properties. > > > > On the other hand, thanks for the suggestion with the object cast. That > gave brought my setup performance up to par with the native C# edits! > > > > Edit: SetProviderType Count: 70291 Min: 9.866000E-001 Max: > 5.393440E+001 Total: 6.684688E+004 Setup: 1.904770E+002 > > Edit: SetFeeSchedule Count: 70291 Min: 1.229300E+000 Max: > 6.506160E+001 Total: 9.587090E+004 Setup: 1.747695E+002 > > Edit: phDefaultNetworkCode Count: 70291 Min: 9.700000E-003 Max: > 2.347088E+002 Total: 1.154772E+003 Setup: 1.156382E+002 > > Edit: phCloneFieldList Count: 70291 Min: 3.200000E-003 Max: > 4.007700E+000 Total: 2.727729E+002 Setup: 1.137180E+002 > > Edit: phAssignValueToField Count: 70291 Min: 4.400000E-003 Max: > 1.205800E+000 Total: 4.475063E+002 Setup: 1.152221E+002 > > > > On Thu, Aug 12, 2010 at 11:42 AM, Dino Viehland > wrote: > > I?d suggest doing mScope.PH = editScope. That will create a rule which > will get cached and will generally run faster than passing the string > directly. > > > > The only other thing I can think of is maybe there?s something odd w/ rule > being produced because ?editScope? is a dynamic object in SetupEdit so ?mScope.SetVariable("PH", > editScope);? ends up dispatching dynamically. If you did ?mScope.SetVariable("PH", > (object)editScope);? it would dispatch statically. > > > > If neither of those solutions helps I can see if I can look deeper and see > if I can repro it. There were some issues w/ IronPython 2.6 where this was > really slow but they should have been fixed w/ 2.6.1. > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Cory Brostowicz > *Sent:* Thursday, August 12, 2010 7:34 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] ScriptScope.SetVariable() performance > > > > Hello, > > > > I'm trying to get more performance out of my IronPython scripts inside one > of my applications, and noticed I'm spending the bulk of my time setting up > the ScriptScope prior to execution. My applications translates information > coming from a flat file, and I use IronPython to enforce business rules on > various records that I pull from my input file. The object that I'm passing > to the scope is custom implementation of the ExpandoObject. > > > > Am I doing anything out of the ordinary here, or is there a better way to > get the performance I'm after? It doesn't seem like setting up the script > should performance significantly slower than executing the script itself. > > > Here is an example of the performance results I'm getting. I'm keeping > track of various timings for execution time, but the script setup timer is > really just stopping and starting a stopwatch before and after each call to > ScriptScope.SetVariable()... > > > > > > DUMPING EDIT STATS > > ------------------ > > > > Edit: SetProviderType Count: 70291 Min: 9.927000E-001 Max: > 4.922160E+001 Total: 7.656987E+004 Setup: 4.667084E+005 > > Edit: SetFeeSchedule Count: 70291 Min: 1.572500E+000 Max: > 6.547200E+001 Total: 1.067754E+005 Setup: 4.639014E+005 > > Edit: phDefaultNetworkCode Count: 70291 Min: 1.900000E-002 Max: > 2.413129E+002 Total: 1.618541E+003 Setup: 1.161743E+002 > > Edit: phCloneFieldList Count: 70291 Min: 4.400000E-003 Max: > 4.083400E+000 Total: 3.565259E+002 Setup: 1.113712E+002 > > Edit: phAssignValueToField Count: 70291 Min: 9.700000E-003 Max: > 1.777100E+000 Total: 5.765196E+002 Setup: 1.108866E+002 > > > > > > SetProviderType and SetFeeSchedule are both IronPython scripts, the other > three are C# edits that I'm passing my ExpandoObject directly to. > > > > 4.667 E+005 = almost 8 minutes... > > 1.108 E+002 = .1 seconds > > > > > > Thanks in advance for any advice you can help me with. > > > > -Cory > > > > class IronPythonScriptHost : PrimeEditBase { > > ScriptSource mScriptSource; > > ScriptEngine mEngine; > > ScriptScope mScope; > > > > public IronPythonScriptHost(string scriptText, string > ScriptName, CommandLine mCommandLine, string[] mEditParms, ScriptEngine > engine) > > : base(mCommandLine, mEditParms) { > > mEditName = ScriptName; > > mIsScript = true; > > mEngine = engine; > > mScriptSource = > mEngine.CreateScriptSourceFromString(scriptText, > Microsoft.Scripting.SourceCodeKind.File); > > mScriptSource.Compile(); > > mScope = mEngine.CreateScope(); > > } > > public override void SetupEdit(dynamic editScope) { > > > > StartSetupTimer(); > > mScope.SetVariable("PH", editScope); > > StopSetupTimer(); > > } > > > > public override void performEdit() { > > StartExecutionTimer(); > > try { > > > mScriptSource.Execute(mScope); > > CleanupEdit(); > > } catch (Exception ex) { > > ExceptionOperations ExcOps = > mEngine.GetService(); > > throw new > Exception("Exception during execution of " + base.EditName + ". " + > ex.Message + "\r\n" + ExcOps.FormatException(ex)); > > } > > StopAndRecordExecutionTimer(); > > } > > } > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristopher.kane at gmail.com Thu Aug 12 22:44:48 2010 From: kristopher.kane at gmail.com (Kristopher Kane) Date: Thu, 12 Aug 2010 16:44:48 -0400 Subject: [IronPython] Access System.Net.NetworkInformation.GetAllNetworkInterfaces() Message-ID: Hello All, First time crawling in .NET and was wondering how to access the list of network interfaces. I am following a C# example from MSDN that goes something like this: NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces(); Then they iterate over adapters to list the interfaces. In IronPython, I am trying to do this: import clr clr.AddReference('System.Net') from System.Net import NetworkInterface a[] = NetworkInformation.GetAllNetworkINterfaces() Then I will iterate over a to list. It returns an Attribute error and says that GetAllNetworkInterfaces of 'NameSpace#' object is read only. This is a strange error to me since I am trying to read from not write to. What have I messed up here? Thanks, -Kris From dinov at microsoft.com Thu Aug 12 22:59:00 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 20:59:00 +0000 Subject: [IronPython] Access System.Net.NetworkInformation.GetAllNetworkInterfaces() In-Reply-To: References: Message-ID: Kristopher wrote: > Hello All, > > First time crawling in .NET and was wondering how to access the list > of network interfaces. > > I am following a C# example from MSDN that goes something like this: > > > > NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces(); > > > Then they iterate over adapters to list the interfaces. > > In IronPython, I am trying to do this: > > > import clr > clr.AddReference('System.Net') > from System.Net import NetworkInterface > > a[] = NetworkInformation.GetAllNetworkINterfaces() > > > > Then I will iterate over a to list. > > It returns an Attribute error and says that GetAllNetworkInterfaces of > 'NameSpace#' object is read only. > It's actually in System.Net.NetworkInformation: >>> System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces() Array[SystemNetworkInterface]((, , )) You also don't need the clr.AddReference because this is in System.dll instead of in System.Net.dll. From dinov at microsoft.com Thu Aug 12 23:01:45 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 21:01:45 +0000 Subject: [IronPython] IronPython 2.6.2 In-Reply-To: <4C63C0AC.4060200@bakalari.cz> References: <4C63C0AC.4060200@bakalari.cz> Message-ID: Lukas wrote: > Hi guys, > do you have a release date for IronPython 2.6.2? Thanks. Thank you for the reminder and I apologize for the delay. There were a couple of failures in the last check-in that I believe I now have investigated and fixed. I'm kicking off another run and if that passes then we can kick off the final release build. So my guess would be late next week or the week after that. Again, sorry for the delay, it's taken way too long to get it out. From dinov at microsoft.com Thu Aug 12 23:05:00 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 21:05:00 +0000 Subject: [IronPython] profiling in IronPython error In-Reply-To: References: Message-ID: In ASP.NET I'm guessing we don't ever make a module called __main__. From the command line when you do "ipy foo.py" foo.py is actually called __main__ and there's no foo module. But if you import foo from an interactive session then it's named foo. You could do something like: import sys sys.modules['__main__'] = foo where foo is whatever the "main" module is. Or if this is your code you could change it to not try to import __main__ or make it try main and then try something else. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pablo Dalmazzo Sent: Thursday, August 12, 2010 7:58 AM To: IronPython Mailing list Subject: [IronPython] profiling in IronPython error Hi guys, Im trying to run this test I had in cPython in IronPython 2.6 in asp.net. from profile import * class Prueba(object): @staticmethod def probarvelocidad(): lista = ['a','b','c'] for x in lista: pass run("Prueba.probarvelocidad()","C:\melia") It doesnt work, i get this Mensaje de error del analizador: No module named __main__ Error de c?digo fuente: (Line 454, import __main__ ) L?nea 452: L?nea 453: def run(self, cmd): L?nea 454: import __main__ Any ideas? can I give any more useful information to know which the problem is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Aug 12 23:14:06 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 Aug 2010 21:14:06 +0000 Subject: [IronPython] Calling COM method returns generic System.__ComObject? In-Reply-To: References: Message-ID: Does just "opc_items_object.AddItem" work at all? That should work if it's an IDispatch com object or if it has IProvideTypeInfo. If not the workaround is to use the interface to dispatch through as you've discovered. Rather than constructing an object with the interface though you do: IComInterface.AddItem(comObject, 'OPC path here', opc_grp_object.ClientHandle) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of yngipy hernan Sent: Wednesday, August 11, 2010 7:21 PM To: Discussion of IronPython Subject: [IronPython] Calling COM method returns generic System.__ComObject? Hi All, I have been playing around IronPython + COM + OPC (COM not the .Net). One of the calls in OPC is (pseudocode): item = opc_items_object.AddItem('OPC path here', opc_grp_object.ClientHandle) The issue is that item is returned as System.__ComObject. All methods that are available for OPCItem interface are gone??? I have search the internet and it seems like opc_items_object should have a coclass for IronPython to figure out how to return object properly. Unfortunately this is not the case, based on the IDL OPCItems don't have a coclass definition. Is there a work-around for this? I have also come across a possible work-around by using unbound class instance, i.e., outParamAsReturnValue = InteropAssemblyNamespace.IComInterface(comObject). But I can't figure out how to use it. I would really appreciate anyone can point me out to the right direction. Regards, Yngipy -------------- next part -------------- An HTML attachment was scrubbed... URL: From yngipy at gmail.com Fri Aug 13 05:37:19 2010 From: yngipy at gmail.com (yngipy hernan) Date: Thu, 12 Aug 2010 22:37:19 -0500 Subject: [IronPython] Calling COM method returns generic System.__ComObject? In-Reply-To: References: Message-ID: RE: Does just ?opc_items_object.AddItem? work at all? Yes, I have a C# program that is happing calling ?opc_items_object.AddItem?. RE: That should work if it?s an IDispatch com object This is what I got from OLE-COM ObjectViewer interface OPCItems : IDispatch { So I am assuming that it is an IDispatch. By the way, my IronPython info is: IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4927 And..... I finally figured out how to call the method from an unbound class. I thought it was a C# thing, it struck me that it was Python's. Finally.... would this be an issue with IronPython? I can file an issue on this one but I am afraid that this can't be replicated in other machines without using a specific implementation of OPC Server. Thanks, Yngipy On Thu, Aug 12, 2010 at 4:14 PM, Dino Viehland wrote: > Does just ?opc_items_object.AddItem? work at all? That should work if > it?s an IDispatch com object or if it has IProvideTypeInfo. > > > > If not the workaround is to use the interface to dispatch through as you?ve > discovered. Rather than constructing an object with the interface though > you do: > > > > IComInterface.AddItem(comObject, 'OPC path here', > opc_grp_object.ClientHandle) > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *yngipy hernan > *Sent:* Wednesday, August 11, 2010 7:21 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] Calling COM method returns generic > System.__ComObject? > > > > Hi All, > > > > I have been playing around IronPython + COM + OPC (COM not the .Net). > > > > One of the calls in OPC is (pseudocode): > > > > item = opc_items_object.AddItem('OPC path here', > opc_grp_object.ClientHandle) > > > > The issue is that item is returned as System.__ComObject. All methods that > are available for OPCItem interface are gone??? > > > > I have search the internet and it seems like opc_items_object should have a > coclass for IronPython to figure out how to return object properly. > Unfortunately this is not the case, based on the IDL OPCItems don't have a > coclass definition. > > > > Is there a work-around for this? > > > > I have also come across a possible work-around by using unbound class > instance, i.e., outParamAsReturnValue = > InteropAssemblyNamespace.IComInterface(comObject). > > > > But I can't figure out how to use it. > > > > I would really appreciate anyone can point me out to the right direction. > > > > Regards, > > Yngipy > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Fri Aug 13 17:38:33 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Fri, 13 Aug 2010 08:38:33 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <7f189a33-3c95-4a46-b187-a0468f40b97d@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75479. MODIFIED SOURCES $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools/Navigation/DropDownBarClient.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/Templates/Projects/WpfProject/Program.py $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/Templates/Projects/WpfProject/WpfApp.zip From michael at voidspace.org.uk Sat Aug 14 01:10:27 2010 From: michael at voidspace.org.uk (Michael Foord) Date: Sat, 14 Aug 2010 00:10:27 +0100 Subject: [IronPython] ironpython.net down Message-ID: <4C65D0E3.9050806@voidspace.org.uk> Hello guys, Looks like someone forgot to pay the hosting bill for ironpython.net (?). Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. From dinov at microsoft.com Sat Aug 14 01:20:55 2010 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 13 Aug 2010 23:20:55 +0000 Subject: [IronPython] ironpython.net down In-Reply-To: <4C65D0E3.9050806@voidspace.org.uk> References: <4C65D0E3.9050806@voidspace.org.uk> Message-ID: I pinged someone about it - Jimmy used to take care of these things :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, August 13, 2010 4:10 PM > To: Discussion of IronPython > Subject: [IronPython] ironpython.net down > > Hello guys, > > Looks like someone forgot to pay the hosting bill for ironpython.net > (?). > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on > behalf of your employer, to release me from all obligations and waivers > arising from any and all NON-NEGOTIATED agreements, licenses, terms-of- > service, shrinkwrap, clickwrap, browsewrap, confidentiality, non- > disclosure, non-compete and acceptable use policies ("BOGUS > AGREEMENTS") that I have entered into with your employer, its partners, > licensors, agents and assigns, in perpetuity, without prejudice to my > ongoing rights and privileges. You further represent that you have the > authority to release me from any BOGUS AGREEMENTS on behalf of your > employer. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Sat Aug 14 01:21:43 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 14 Aug 2010 00:21:43 +0100 Subject: [IronPython] ironpython.net down In-Reply-To: References: <4C65D0E3.9050806@voidspace.org.uk> Message-ID: <4C65D387.6080703@voidspace.org.uk> On 14/08/2010 00:20, Dino Viehland wrote: > I pinged someone about it - Jimmy used to take care of these things :) > > Cool. Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Friday, August 13, 2010 4:10 PM >> To: Discussion of IronPython >> Subject: [IronPython] ironpython.net down >> >> Hello guys, >> >> Looks like someone forgot to pay the hosting bill for ironpython.net >> (?). >> >> Michael Foord >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> READ CAREFULLY. By accepting and reading this email you agree, on >> behalf of your employer, to release me from all obligations and waivers >> arising from any and all NON-NEGOTIATED agreements, licenses, terms-of- >> service, shrinkwrap, clickwrap, browsewrap, confidentiality, non- >> disclosure, non-compete and acceptable use policies ("BOGUS >> AGREEMENTS") that I have entered into with your employer, its partners, >> licensors, agents and assigns, in perpetuity, without prejudice to my >> ongoing rights and privileges. You further represent that you have the >> authority to release me from any BOGUS AGREEMENTS on behalf of your >> employer. >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. From dinov at microsoft.com Sat Aug 14 03:01:29 2010 From: dinov at microsoft.com (Dino Viehland) Date: Sat, 14 Aug 2010 01:01:29 +0000 Subject: [IronPython] ironpython.net down In-Reply-To: <2054073590413246102@unknownmsgid> References: <4C65D0E3.9050806@voidspace.org.uk> <4C65D387.6080703@voidspace.org.uk> <2054073590413246102@unknownmsgid> Message-ID: Yes, but despite you making it clear there's been some delay followed by confusion on what was going to expire and when. > -----Original Message----- > From: Jimmy Schementi [mailto:jschementi at gmail.com] > Sent: Friday, August 13, 2010 5:50 PM > To: Discussion of IronPython > Cc: Dino Viehland; Bill Chiles > Subject: Re: [IronPython] ironpython.net down > > I made it pretty clear that the GoDaddy hosting needed to switch > credit cards, did that not happen? Bill and Dino, you have passwords > for the account. > > On Aug 13, 2010, at 7:21 PM, Michael Foord > wrote: > > > On 14/08/2010 00:20, Dino Viehland wrote: > >> I pinged someone about it - Jimmy used to take care of these things > :) > >> > >> > > > > Cool. > > > > Michael > > > >>> -----Original Message----- > >>> From: users-bounces at lists.ironpython.com [mailto:users- > >>> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >>> Sent: Friday, August 13, 2010 4:10 PM > >>> To: Discussion of IronPython > >>> Subject: [IronPython] ironpython.net down > >>> > >>> Hello guys, > >>> > >>> Looks like someone forgot to pay the hosting bill for > ironpython.net > >>> (?). > >>> > >>> Michael Foord > >>> > >>> -- > >>> http://www.ironpythoninaction.com/ > >>> http://www.voidspace.org.uk/blog > >>> > >>> READ CAREFULLY. By accepting and reading this email you agree, on > >>> behalf of your employer, to release me from all obligations and > waivers > >>> arising from any and all NON-NEGOTIATED agreements, licenses, > terms-of- > >>> service, shrinkwrap, clickwrap, browsewrap, confidentiality, non- > >>> disclosure, non-compete and acceptable use policies ("BOGUS > >>> AGREEMENTS") that I have entered into with your employer, its > partners, > >>> licensors, agents and assigns, in perpetuity, without prejudice to > my > >>> ongoing rights and privileges. You further represent that you have > the > >>> authority to release me from any BOGUS AGREEMENTS on behalf of your > >>> employer. > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.ironpython.com > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > > > > > > -- > > http://www.ironpythoninaction.com/ > > http://www.voidspace.org.uk/blog > > > > READ CAREFULLY. By accepting and reading this email you agree, on > behalf of your employer, to release me from all obligations and waivers > arising from any and all NON-NEGOTIATED agreements, licenses, terms-of- > service, shrinkwrap, clickwrap, browsewrap, confidentiality, non- > disclosure, non-compete and acceptable use policies ("BOGUS > AGREEMENTS") that I have entered into with your employer, its partners, > licensors, agents and assigns, in perpetuity, without prejudice to my > ongoing rights and privileges. You further represent that you have the > authority to release me from any BOGUS AGREEMENTS on behalf of your > employer. > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From pablodalma93 at hotmail.com Sat Aug 14 14:33:40 2010 From: pablodalma93 at hotmail.com (Pablo Dalmazzo) Date: Sat, 14 Aug 2010 09:33:40 -0300 Subject: [IronPython] profiling in IronPython error In-Reply-To: References: , Message-ID: I followed your recommendation and now I get this, 'module' object has no attribute 'setprofile' sys.setprofile(self.dispatcher) I used the profile module from an IronPython 2.6 installation. I also found this in the web, In other words, another Python implementation like IronPython is within its own right not to implement these functions. As a matter of fact: IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> sys.settrace(f) Traceback (most recent call last): NotImplementedError: sys.settrace is not yet supported by IronPython >>> sys.setprofile(f) Traceback (most recent call last): AttributeError: 'module' object has no attribute 'setprofile' is that implemented / going to be implemented in another IronPython version or should I use another profiler with IronPython? If so, could you recommend me one? Greetings From: dinov at microsoft.com To: users at lists.ironpython.com Date: Thu, 12 Aug 2010 21:05:00 +0000 Subject: Re: [IronPython] profiling in IronPython error In ASP.NET I?m guessing we don?t ever make a module called __main__. From the command line when you do ?ipy foo.py? foo.py is actually called __main__ and there?s no foo module. But if you import foo from an interactive session then it?s named foo. You could do something like: import sys sys.modules[?__main__?] = foo where foo is whatever the ?main? module is. Or if this is your code you could change it to not try to import __main__ or make it try main and then try something else. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pablo Dalmazzo Sent: Thursday, August 12, 2010 7:58 AM To: IronPython Mailing list Subject: [IronPython] profiling in IronPython error Hi guys, Im trying to run this test I had in cPython in IronPython 2.6 in asp.net. from profile import * class Prueba(object): @staticmethod def probarvelocidad(): lista = ['a','b','c'] for x in lista: pass run("Prueba.probarvelocidad()","C:\melia") It doesnt work, i get this Mensaje de error del analizador: No module named __main__ Error de c?digo fuente: (Line 454, import __main__ ) L?nea 452: L?nea 453: def run(self, cmd): L?nea 454: import __main__ Any ideas? can I give any more useful information to know which the problem is? _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustaq2001 at gmail.com Mon Aug 16 14:49:08 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Mon, 16 Aug 2010 18:19:08 +0530 Subject: [IronPython] Microsoft.Scripting Assembly Version 1.0 does not contain Microsoft.Scripting.Hosting.Shell Namesapce Message-ID: Hi, I was using Microsoft.Scripting.dll (version 0.9) which was packaged with Iron Python 2.0.1. This assembly contains "Microsoft.Scripting.Hosting.Shell" Namesapce. I was using an Enum "Style" from this namespace. Now I upgraded to Iron Python 2.6.1. Here I observed that Microsoft.Scripting assembly does not contain "Microsoft.Scripting.Hosting.Shell" namespace. Could you please point me to where the Enum "Style" is located or its equivalent Enum in this version. thanks, Mustaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Mon Aug 16 17:09:25 2010 From: dfugate at microsoft.com (Dave Fugate) Date: Mon, 16 Aug 2010 15:09:25 +0000 Subject: [IronPython] Microsoft.Scripting Assembly Version 1.0 does not contain Microsoft.Scripting.Hosting.Shell Namesapce In-Reply-To: References: Message-ID: <299545F35D442642800736DBA0C3AA2803433733@TK5EX14MBXC201.redmond.corp.microsoft.com> Try Microsoft.Dynamic.dll ;) Dave From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mohammad mustaq Sent: Monday, August 16, 2010 5:49 AM To: Discussion of IronPython Subject: [IronPython] Microsoft.Scripting Assembly Version 1.0 does not contain Microsoft.Scripting.Hosting.Shell Namesapce Hi, I was using Microsoft.Scripting.dll (version 0.9) which was packaged with Iron Python 2.0.1. This assembly contains "Microsoft.Scripting.Hosting.Shell" Namesapce. I was using an Enum "Style" from this namespace. Now I upgraded to Iron Python 2.6.1. Here I observed that Microsoft.Scripting assembly does not contain "Microsoft.Scripting.Hosting.Shell" namespace. Could you please point me to where the Enum "Style" is located or its equivalent Enum in this version. thanks, Mustaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustaq2001 at gmail.com Tue Aug 17 04:29:34 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Tue, 17 Aug 2010 07:59:34 +0530 Subject: [IronPython] Microsoft.Scripting Assembly Version 1.0 does not contain Microsoft.Scripting.Hosting.Shell Namesapce In-Reply-To: <299545F35D442642800736DBA0C3AA2803433733@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <299545F35D442642800736DBA0C3AA2803433733@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-ID: Yes, it has the required namespace. Thanks :) On Mon, Aug 16, 2010 at 8:39 PM, Dave Fugate wrote: > Try Microsoft.Dynamic.dll ;) > > > > Dave > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq > *Sent:* Monday, August 16, 2010 5:49 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Microsoft.Scripting Assembly Version 1.0 does not > contain Microsoft.Scripting.Hosting.Shell Namesapce > > > > > Hi, > > I was using Microsoft.Scripting.dll (version 0.9) which was packaged with > Iron Python 2.0.1. This assembly contains > "Microsoft.Scripting.Hosting.Shell" Namesapce. I was using an Enum "Style" > from this namespace. Now I upgraded to Iron Python 2.6.1. Here I observed > that Microsoft.Scripting assembly does not contain > "Microsoft.Scripting.Hosting.Shell" namespace. Could you please point me to > where the Enum "Style" is located or its equivalent Enum in this version. > > thanks, > Mustaq > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Tue Aug 17 17:39:56 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 17 Aug 2010 08:39:56 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75728. ADDED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/WiX $/IronPython/IronPython_Main/Languages/IronPython/WiX/build.bat $/IronPython/IronPython_Main/Languages/IronPython/WiX/Core.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/DLR.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/getModuleList.py $/IronPython/IronPython_Main/Languages/IronPython/WiX/IpyRedist.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/IronPython.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/IronStudio.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/MsiLicense.rtf $/IronPython/IronPython_Main/Languages/IronPython/WiX/Tutorial.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/Version.wxi MODIFIED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython.Modules/math.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Modules/Builtin.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ByteArray.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/MetaUserObject.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Operations/ComplexOps.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Operations/StringOps.cs $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_builtinfunc.py $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_complex.py $/IronPython/IronPython_Main/Languages/IronPython/WiX/build.bat $/IronPython/IronPython_Main/Languages/IronPython/WiX/Core.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/DLR.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/getModuleList.py $/IronPython/IronPython_Main/Languages/IronPython/WiX/IpyRedist.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/IronPython.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/IronStudio.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/MsiLicense.rtf $/IronPython/IronPython_Main/Languages/IronPython/WiX/Tutorial.wxs $/IronPython/IronPython_Main/Languages/IronPython/WiX/Version.wxi CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1975463 Date: 8/17/2010 8:27:12 AM Switches some CPython tests to run against 2.7 in SNAP Fixes the following issues: - builtin callable() has incorrect behavior on user objects - 27902 - builtin range() now rejects float arguments - bytearray constructor now accepts bigints - str.find and str.rfind no longer overflow on large start indices - added fast path for math.copysign - 27988 - removed * from complex repr (e.g. ?nan*j?) (Shelveset: 27Snap02;REDMOND\ddicato | SNAP CheckinId: 11278) From cenovsky at bakalari.cz Tue Aug 17 23:41:00 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 17 Aug 2010 23:41:00 +0200 Subject: [IronPython] Hosting IronPython in Silverlight - background loading Message-ID: <4C6B01EC.2040706@bakalari.cz> Hi all, is it possible to load IronPython engine in the background thread in Silverlight? I tried to load it via BackgroundWorker: private void UserControl_Loaded(object sender, RoutedEventArgs ev) { IPloader = new BackgroundWorker(); IPloader.DoWork += new DoWorkEventHandler((s, e) => { runtime = DynamicEngine.CreateRuntime(true); // debug mode true engine = runtime.GetEngine("python"); } ); IPloader.RunWorkerCompleted += new RunWorkerCompletedEventHandler((s, e) => { this.textBlock1.Text = "IronPython loaded"; } ); IPloader.RunWorkerAsync(); } It fails with the following exception: System.UnauthorizedAccessException was unhandled by user code Message=Invalid cross-thread access. StackTrace: at MS.Internal.XcpImports.CheckThread() at System.Windows.DependencyObject.GetValueInternal(DependencyProperty dp) at System.Windows.Deployment.get_Parts() at Microsoft.Scripting.Silverlight.DynamicAppManifest.AssemblyParts() at Microsoft.Scripting.Silverlight.DynamicAppManifest..ctor() at Microsoft.Scripting.Silverlight.DynamicEngine.CreateLangConfig() at Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntimeSetup(Boolean debugMode) at Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime(Boolean debugMode) at SLHosting.MainPage.b__0(Object s, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnRun(Object argument) InnerException: Thanks for any advice. -- -- Luk?? From curylod at asme.org Wed Aug 18 04:15:14 2010 From: curylod at asme.org (Dave Curylo) Date: Tue, 17 Aug 2010 22:15:14 -0400 Subject: [IronPython] Hosting IronPython in Silverlight - background loading In-Reply-To: <4C6B01EC.2040706@bakalari.cz> References: <4C6B01EC.2040706@bakalari.cz> Message-ID: Lukas, I think the problem is the RunWorkerCompleted handler trying to update the UI. Wrap calls from a background thread to update UI controls in something like this so the Dispatcher updates any controls on the UI thread: this.Dispatcher.BeginInvoke(() => { this.textBlock1.Text = "IronPython loaded"; }); Hope that helps. -Dave 2010/8/17 Lukas Cenovsky > Hi all, > is it possible to load IronPython engine in the background thread in > Silverlight? > > I tried to load it via BackgroundWorker: > > private void UserControl_Loaded(object sender, RoutedEventArgs ev) > { > IPloader = new BackgroundWorker(); > IPloader.DoWork += new DoWorkEventHandler((s, e) => > { > runtime = DynamicEngine.CreateRuntime(true); // debug mode true > engine = runtime.GetEngine("python"); > } > ); > IPloader.RunWorkerCompleted += new RunWorkerCompletedEventHandler((s, e) > => > { > this.textBlock1.Text = "IronPython loaded"; > } > ); > IPloader.RunWorkerAsync(); > } > > It fails with the following exception: > > System.UnauthorizedAccessException was unhandled by user code > Message=Invalid cross-thread access. > StackTrace: > at MS.Internal.XcpImports.CheckThread() > at > System.Windows.DependencyObject.GetValueInternal(DependencyProperty dp) > at System.Windows.Deployment.get_Parts() > at Microsoft.Scripting.Silverlight.DynamicAppManifest.AssemblyParts() > at Microsoft.Scripting.Silverlight.DynamicAppManifest..ctor() > at Microsoft.Scripting.Silverlight.DynamicEngine.CreateLangConfig() > at > Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntimeSetup(Boolean > debugMode) > at > Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime(Boolean > debugMode) > at SLHosting.MainPage.b__0(Object s, > DoWorkEventArgs e) > at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) > at System.ComponentModel.BackgroundWorker.OnRun(Object argument) > InnerException: > > Thanks for any advice. > > -- > -- Luk?? > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at schementi.com Wed Aug 18 05:05:25 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Tue, 17 Aug 2010 23:05:25 -0400 Subject: [IronPython] Hosting IronPython in Silverlight - background loading In-Reply-To: References: <4C6B01EC.2040706@bakalari.cz> Message-ID: True, but according to his exception stack it never gets there ... it throws on the "runtime = DynamicEngine.CreateRuntime(true);" line. It throws because somewhere in that method it doesn't dispatch to the UI thread as you described. Those are the fixes I need to do. ~Jimmy 2010/8/17 Dave Curylo > Lukas, > > I think the problem is the RunWorkerCompleted handler trying to update the > UI. Wrap calls from a background thread to update UI controls in something > like this so the Dispatcher updates any controls on the UI thread: > > this.Dispatcher.BeginInvoke(() => > { > this.textBlock1.Text = "IronPython loaded"; > }); > > Hope that helps. > > -Dave > > 2010/8/17 Lukas Cenovsky > > Hi all, >> is it possible to load IronPython engine in the background thread in >> Silverlight? >> >> I tried to load it via BackgroundWorker: >> >> private void UserControl_Loaded(object sender, RoutedEventArgs ev) >> { >> IPloader = new BackgroundWorker(); >> IPloader.DoWork += new DoWorkEventHandler((s, e) => >> { >> runtime = DynamicEngine.CreateRuntime(true); // debug mode true >> engine = runtime.GetEngine("python"); >> } >> ); >> IPloader.RunWorkerCompleted += new RunWorkerCompletedEventHandler((s, >> e) => >> { >> this.textBlock1.Text = "IronPython loaded"; >> } >> ); >> IPloader.RunWorkerAsync(); >> } >> >> It fails with the following exception: >> >> System.UnauthorizedAccessException was unhandled by user code >> Message=Invalid cross-thread access. >> StackTrace: >> at MS.Internal.XcpImports.CheckThread() >> at >> System.Windows.DependencyObject.GetValueInternal(DependencyProperty dp) >> at System.Windows.Deployment.get_Parts() >> at >> Microsoft.Scripting.Silverlight.DynamicAppManifest.AssemblyParts() >> at Microsoft.Scripting.Silverlight.DynamicAppManifest..ctor() >> at Microsoft.Scripting.Silverlight.DynamicEngine.CreateLangConfig() >> at >> Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntimeSetup(Boolean >> debugMode) >> at >> Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime(Boolean >> debugMode) >> at SLHosting.MainPage.b__0(Object s, >> DoWorkEventArgs e) >> at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs >> e) >> at System.ComponentModel.BackgroundWorker.OnRun(Object argument) >> InnerException: >> >> Thanks for any advice. >> >> -- >> -- Luk?? >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yngipy at gmail.com Wed Aug 18 07:25:35 2010 From: yngipy at gmail.com (yngipy hernan) Date: Wed, 18 Aug 2010 00:25:35 -0500 Subject: [IronPython] Chasing memory leak in IronPython scripts Message-ID: Hi All, I have an IronPython script that is using/talking to COM server. I am not sure if I have a memory leak but the IronPython Private Byte keeps on growing. I haven't seen it run of memory but I might be leaking memory. Essential I am using an interop dll to connect to the COM server. Call some methods and disconnects. I have created another script to stress test this "library" to basically connect to COM server. Then repeatedly create COM objects, call methods, do intermediate cleanup by calling Marshal.ReleaseComObject. This part seems like leaking memory. Now my question is: - Can anyone point me to a tutorial on detecting memory leak in IronPython? - Do we have tools that can help me in detecting any dangling objects? Regards, Yngipy -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Wed Aug 18 08:27:52 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Wed, 18 Aug 2010 08:27:52 +0200 Subject: [IronPython] Chasing memory leak in IronPython scripts In-Reply-To: References: Message-ID: <4C6B7D68.7040804@bakalari.cz> On 18.8.2010 7:25, yngipy hernan wrote: > Hi All, > > I have an IronPython script that is using/talking to COM server. I am > not sure if I have a memory leak but the IronPython Private Byte keeps > on growing. I haven't seen it run of memory but I might be leaking memory. > > Essential I am using an interop dll to connect to the COM server. Call > some methods and disconnects. I have created another script to stress > test this "library" to basically connect to COM server. Then > repeatedly create COM objects, call methods, do intermediate cleanup > by calling Marshal.ReleaseComObject. This part seems like leaking memory. > > Now my question is: > - Can anyone point me to a tutorial on detecting memory leak in > IronPython? > - Do we have tools that can help me in detecting any dangling objects? WinDbg is you friend for your problem. Check this blog: http://blog.kamil.dworakowski.name/2008/02/debugging-memory-problems-in-ironpython.html -- -- Luk?? From cenovsky at bakalari.cz Wed Aug 18 09:23:20 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Wed, 18 Aug 2010 09:23:20 +0200 Subject: [IronPython] Hosting IronPython in Silverlight - background loading In-Reply-To: References: <4C6B01EC.2040706@bakalari.cz> Message-ID: <4C6B8A68.8070901@bakalari.cz> An HTML attachment was scrubbed... URL: From jimmy at schementi.com Wed Aug 18 15:44:33 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Wed, 18 Aug 2010 09:44:33 -0400 Subject: [IronPython] Hosting IronPython in Silverlight - background loading In-Reply-To: <4C6B8A68.8070901@bakalari.cz> References: <4C6B01EC.2040706@bakalari.cz> <4C6B8A68.8070901@bakalari.cz> Message-ID: Lukas, this is the bug in Microsoft.Scripting.Silverlight. Because you do "setup.HostType = typeof(Microsoft.Scripting.Silverlight.BrowserScriptHost)", all file-system lookups (like looking for a module) go through that type. ~Jimmy On Wed, Aug 18, 2010 at 3:23 AM, Lukas Cenovsky wrote: > Looks like there is a bug in DynamicEngine. When I tried the old way, it > works: > > private void UserControl_Loaded(object sender, RoutedEventArgs ev) > { > IPloader = new BackgroundWorker(); > IPloader.DoWork += new DoWorkEventHandler((s, e) => > { > ScriptRuntimeSetup setup = new ScriptRuntimeSetup(); > setup.LanguageSetups.Add(Python.CreateLanguageSetup(null)); > setup.HostType = > typeof(Microsoft.Scripting.Silverlight.BrowserScriptHost); > setup.DebugMode = true; > runtime = new ScriptRuntime(setup); > engine = Python.GetEngine(runtime); > foreach (string str in new string[] { "mscorlib", "System", > "System.Windows", "System.Windows.Browser", "System.Net" }) > { > > runtime.LoadAssembly(runtime.Host.PlatformAdaptationLayer.LoadAssembly(str)); > } > // engine.Execute("import imptest"); --this does not work > > } > ); > IPloader.RunWorkerCompleted += new RunWorkerCompletedEventHandler((s, > e) => > { > this.textBlock1.Text = "IronPython loaded"; > } > ); > IPloader.RunWorkerAsync(); > } > > What does not work is importing modules in the background thread (commented > line). It throws the following exception: > > System.InvalidOperationException was unhandled by user code > Message=This operation can only occur on the UI Thread. > StackTrace: > at > Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] args, > Boolean& shouldOptimize) > at > IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite > site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 > arg3) > at > System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) > at IronPython.Runtime.Importer.Import(CodeContext context, String > fullName, PythonTuple from, Int32 level) > at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext > context, String fullName, Int32 level) > at > Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame > frame) > at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame > frame) > at Microsoft.Scripting.Interpreter.LightLambda.Run1[T0,TRet](T0 > arg0) > at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope) > at IronPython.Compiler.RuntimeScriptCode.Run() > at Microsoft.Scripting.SourceUnit.Execute() > at Microsoft.Scripting.Hosting.ScriptSource.Execute() > at Microsoft.Scripting.Hosting.ScriptEngine.Execute(String > expression) > > at SLHosting.MainPage.b__0(Object s, > DoWorkEventArgs e) > at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs > e) > at System.ComponentModel.BackgroundWorker.OnRun(Object argument) > InnerException: > > > runtime.ImportModule("imptest"); is similar story so I guess it cannot be > done, right? > > -- > -- Luk?? > > > > On 18.8.2010 5:05, Jimmy Schementi wrote: > > True, but according to his exception stack it never gets there ... it > throws on the "runtime = DynamicEngine.CreateRuntime(true);" line. It throws > because somewhere in that method it doesn't dispatch to the UI thread as you > described. Those are the fixes I need to do. > > ~Jimmy > > > 2010/8/17 Dave Curylo > >> Lukas, >> >> I think the problem is the RunWorkerCompleted handler trying to update >> the UI. Wrap calls from a background thread to update UI controls in >> something like this so the Dispatcher updates any controls on the UI thread: >> >> this.Dispatcher.BeginInvoke(() => >> { >> this.textBlock1.Text = "IronPython loaded"; >> }); >> >> Hope that helps. >> >> -Dave >> >> 2010/8/17 Lukas Cenovsky >> >> Hi all, >>> is it possible to load IronPython engine in the background thread in >>> Silverlight? >>> >>> I tried to load it via BackgroundWorker: >>> >>> private void UserControl_Loaded(object sender, RoutedEventArgs ev) >>> { >>> IPloader = new BackgroundWorker(); >>> IPloader.DoWork += new DoWorkEventHandler((s, e) => >>> { >>> runtime = DynamicEngine.CreateRuntime(true); // debug mode >>> true >>> engine = runtime.GetEngine("python"); >>> } >>> ); >>> IPloader.RunWorkerCompleted += new RunWorkerCompletedEventHandler((s, >>> e) => >>> { >>> this.textBlock1.Text = "IronPython loaded"; >>> } >>> ); >>> IPloader.RunWorkerAsync(); >>> } >>> >>> It fails with the following exception: >>> >>> System.UnauthorizedAccessException was unhandled by user code >>> Message=Invalid cross-thread access. >>> StackTrace: >>> at MS.Internal.XcpImports.CheckThread() >>> at >>> System.Windows.DependencyObject.GetValueInternal(DependencyProperty dp) >>> at System.Windows.Deployment.get_Parts() >>> at >>> Microsoft.Scripting.Silverlight.DynamicAppManifest.AssemblyParts() >>> at Microsoft.Scripting.Silverlight.DynamicAppManifest..ctor() >>> at Microsoft.Scripting.Silverlight.DynamicEngine.CreateLangConfig() >>> at >>> Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntimeSetup(Boolean >>> debugMode) >>> at >>> Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime(Boolean >>> debugMode) >>> at SLHosting.MainPage.b__0(Object s, >>> DoWorkEventArgs e) >>> at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs >>> e) >>> at System.ComponentModel.BackgroundWorker.OnRun(Object argument) >>> InnerException: >>> >>> Thanks for any advice. >>> >>> -- >>> -- Luk?? >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing listUsers at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drken567 at gmail.com Wed Aug 18 17:35:46 2010 From: drken567 at gmail.com (Ken MacDonald) Date: Wed, 18 Aug 2010 11:35:46 -0400 Subject: [IronPython] WPF / ipy: renewing data binding? Could use some guidance. Message-ID: I have inherited a WPF/ipy app which is using data binding / CollectionView to interact with a customer list. Steps are roughly: 1. query cust. list from DB, sorted by name 2. bind this to a CollectionView 3. step through the list, displaying 1 cust. at a time using the CollectionView.Next/Previous (forget the exact name) operators, moved thru the list in alpha-sorted order 4. re-sort the list by, say, customer type. Still moves thru the list with Next/Previous except now sorted by type, no longer by alpha. Perfect so far, but............ 5. New customers (maybe) have been added to the DB. I re-query the customer list to pick up any new ones. The new list is sorted by customer type (remembered my last sort criteria). 6. bind this to a CollectionView. 7. step thru the list, using Next/Previous on the CollectionView. The customers appear in *utterly random order*, not by alpha, not by customer type. So, I'm a bit stymied. I've been looking through the MSDN but haven't seen anything that addresses how to update CollectionView/data binding to reflect new data in the customer list, or whether it is, in fact, possible to do so. I've found a couple of hints, and tried dozens of variations on the code that seems like it should "just work". It's quite tempting to just maintain my own lists and navigation in python. I've deliberately NOT included any code; for one thing, it's scattered over a number of modules of python (and XAML) but am interested in how any of you would approach the re-binding-to-new-data problem; also, if any of you tried it and found it equally as bizarre and arcane and impossible as it seems to be for my app. Thanks! Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Wed Aug 18 17:38:39 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 18 Aug 2010 08:38:39 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <6ac3aa0c-530e-4e45-8110-1c518c16263c@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75792. DELETED SOURCES $/IronPython/IronPython_Main/Tools/IronStudio/Bin MODIFIED SOURCES $/IronPython/IronPython_Main/Config/Signed/App.config $/IronPython/IronPython_Main/Hosts/Silverlight/Microsoft.Scripting.SilverLight/BrowserScriptHost.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Ast/ExpressionCollectionBuilder.cs $/IronPython/IronPython_Main/Solutions/IronPythonTools.sln $/IronPython/IronPython_Main/Tools/IronStudio/Common.proj $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/IronPythonTools.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore/Repl/RemotePythonEvaluator.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/IronStudio.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore.csproj $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/RemoteEvaluation/RemoteScriptFactory.cs $/IronPython/IronPython_Main/Tools/IronStudio/RemoteScriptFactory/RemoteScriptFactory.csproj From cenovsky at bakalari.cz Wed Aug 18 18:15:09 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Wed, 18 Aug 2010 18:15:09 +0200 Subject: [IronPython] WPF / ipy: renewing data binding? Could use some guidance. In-Reply-To: References: Message-ID: <4C6C070D.8020607@bakalari.cz> Have you tried manually refreshing the CollectionView after update by CollectionView.Refresh()? -- -- Luk?s( On 18.8.2010 17:35, Ken MacDonald wrote: > I have inherited a WPF/ipy app which is using data binding / > CollectionView to interact with a customer list. Steps are roughly: > > 1. query cust. list from DB, sorted by name > 2. bind this to a CollectionView > 3. step through the list, displaying 1 cust. at a time using the > CollectionView.Next/Previous (forget the exact name) operators, > moved thru the list in alpha-sorted order > 4. re-sort the list by, say, customer type. Still moves thru the list > with Next/Previous except now sorted by type, no longer by alpha. > Perfect so far, but............ > > 5. New customers (maybe) have been added to the DB. I re-query the > customer list to pick up any new ones. The new list is sorted by > customer type (remembered my last sort criteria). > 6. bind this to a CollectionView. > 7. step thru the list, using Next/Previous on the CollectionView. The > customers appear in *utterly random order*, not by alpha, not by > customer type. > > So, I'm a bit stymied. I've been looking through the MSDN but haven't > seen anything that addresses how to update CollectionView/data binding > to reflect new data in the customer list, or whether it is, in fact, > possible to do so. I've found a couple of hints, and tried dozens of > variations on the code that seems like it should "just work". It's > quite tempting to just maintain my own lists and navigation in python. > > I've deliberately NOT included any code; for one thing, it's scattered > over a number of modules of python (and XAML) but am interested in how > any of you would approach the re-binding-to-new-data problem; also, if > any of you tried it and found it equally as bizarre and arcane and > impossible as it seems to be for my app. > Thanks! > Ken > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From drken567 at gmail.com Wed Aug 18 18:16:16 2010 From: drken567 at gmail.com (Ken MacDonald) Date: Wed, 18 Aug 2010 12:16:16 -0400 Subject: [IronPython] WPF / ipy: renewing data binding? Could use some guidance. In-Reply-To: <4C6C070D.8020607@bakalari.cz> References: <4C6C070D.8020607@bakalari.cz> Message-ID: Yep. seems to have no effect. Ken On Wed, Aug 18, 2010 at 12:15 PM, Lukas Cenovsky wrote: > Have you tried manually refreshing the CollectionView after update by > CollectionView.Refresh()? > > -- > -- Luk?? > > > > On 18.8.2010 17:35, Ken MacDonald wrote: > > I have inherited a WPF/ipy app which is using data binding / CollectionView > to interact with a customer list. Steps are roughly: > > 1. query cust. list from DB, sorted by name > 2. bind this to a CollectionView > 3. step through the list, displaying 1 cust. at a time using the > CollectionView.Next/Previous (forget the exact name) operators, > moved thru the list in alpha-sorted order > 4. re-sort the list by, say, customer type. Still moves thru the list with > Next/Previous except now sorted by type, no longer by alpha. > Perfect so far, but............ > > 5. New customers (maybe) have been added to the DB. I re-query the customer > list to pick up any new ones. The new list is sorted by customer type > (remembered my last sort criteria). > 6. bind this to a CollectionView. > 7. step thru the list, using Next/Previous on the CollectionView. The > customers appear in *utterly random order*, not by alpha, not by customer > type. > > So, I'm a bit stymied. I've been looking through the MSDN but haven't seen > anything that addresses how to update CollectionView/data binding to reflect > new data in the customer list, or whether it is, in fact, possible to do so. > I've found a couple of hints, and tried dozens of variations on the code > that seems like it should "just work". It's quite tempting to just maintain > my own lists and navigation in python. > > I've deliberately NOT included any code; for one thing, it's scattered over > a number of modules of python (and XAML) but am interested in how any of you > would approach the re-binding-to-new-data problem; also, if any of you tried > it and found it equally as bizarre and arcane and impossible as it seems to > be for my app. > Thanks! > Ken > > > _______________________________________________ > Users mailing listUsers at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Aug 18 18:23:52 2010 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 18 Aug 2010 16:23:52 +0000 Subject: [IronPython] Chasing memory leak in IronPython scripts In-Reply-To: <4C6B7D68.7040804@bakalari.cz> References: <4C6B7D68.7040804@bakalari.cz> Message-ID: Also you might want to compare private bytes vs. the size of the GC heap (in perfmon) to get an idea if it's an unmanaged or managed leak given this is involving interop. One possibility is also that the finalizer thread is being blocked from cleaning up STA COM objects. You could try running IronPython w/ the -X:MTA option if you haven't as this frequently solves that problem. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Lukas Cenovsky > Sent: Tuesday, August 17, 2010 11:28 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Chasing memory leak in IronPython scripts > > On 18.8.2010 7:25, yngipy hernan wrote: > > Hi All, > > > > I have an IronPython script that is using/talking to COM server. I am > > not sure if I have a memory leak but the IronPython Private Byte keeps > > on growing. I haven't seen it run of memory but I might be leaking memory. > > > > Essential I am using an interop dll to connect to the COM server. Call > > some methods and disconnects. I have created another script to stress > > test this "library" to basically connect to COM server. Then > > repeatedly create COM objects, call methods, do intermediate cleanup > > by calling Marshal.ReleaseComObject. This part seems like leaking memory. > > > > Now my question is: > > - Can anyone point me to a tutorial on detecting memory leak in > > IronPython? > > - Do we have tools that can help me in detecting any dangling objects? > > WinDbg is you friend for your problem. Check this blog: > http://blog.kamil.dworakowski.name/2008/02/debugging-memory-problems-in- > ironpython.html > > -- > -- Luk?? > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From maxyaffe at gmail.com Wed Aug 18 19:41:28 2010 From: maxyaffe at gmail.com (Max Yaffe) Date: Wed, 18 Aug 2010 13:41:28 -0400 Subject: [IronPython] If not IronPython, what? Message-ID: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> I've been reading the buzz around Microsoft's reduced commitment to Iron* languages and wondering if I should rethink my own commitment to IronPython. To fill you in, I'm a designer of instruments and software for scientific data acquisition and analysis. My current software uses a dynamic language for scripting in a Win32 based framework program for acquisition and VBA scripting in a VB program for analysis. We decided to rewrite the whole thing in C#+.Net4+IronPython. On stackoverflow, someone asked about using Iron* vs PowerShell for scripting in a C# application in light of Microsoft's changing committment. This was my answer: > I'm in a similar position. > I decided to use IronPython scripting but ever since I saw Anders Hejlsberg's > talk "The Future of C#", I've had a feeling IronPython was doomed. > > It was in Microsoft's interest to get the DLR developed but they ultimately > want us to use tools and languages they control. After all, aren't you using > C# and not Java? So what will a Microsoft dynamic language look like? How > about dynamic, interpreted C# (Iron C#)? Hejlsberg's talk made it clear it > isn't that far away. He even had a console window with a REPL interface. > That said, there's always a possibility for Iron VB. Talk about closing the > loop. > > On the plus side for us programmers, Iron C# also solves another problem that > I'm having trouble with -- the existence of two parallel object environments, > one of .Net objects, one of Python objects. It takes work to get from one to > the other. I assume an Iron C# would utilize the .Net class structure. > > My advice: Stick with Iron Python and .Net classes. When Iron VB or Iron C# > happens, it'll be a quick, maybe automatic, language translation. Besides, > if enough of us use IronPython, Microsoft may change their mindset. So my question to you is a) am I thinking correctly about the future of IronPython, and 2) if not IronPython, what scripting language should I be considering for a .Net C# application? I should let you know I'm also considering switching to Qt/PyQt/Cpython. Thanks for your input. Max From loocas at duber.cz Wed Aug 18 19:48:15 2010 From: loocas at duber.cz (=?UTF-8?B?THVrw6HFoSBEdWLEm2Rh?=) Date: Wed, 18 Aug 2010 19:48:15 +0200 Subject: [IronPython] If not IronPython, what? In-Reply-To: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: <4C6C1CDF.7020406@duber.cz> Hi there, well, honestly, you're at least in a possition where you can make a choice. We here are, on the other hand, solely dependant on IPy. There are no alternatives to what we're using here at the studio. But even still, I think IPy is such a powerful tool that even if Microsoft ditched its support, we can use and leverage on it for years to come. At least in our case. But I seriously doubt Microsoft will completely abandon IPy as that's the only Python alternative for .NET. The .NET CPython initiative is almost dead. I haven't seen an update for ages, unfortunately. But if IPy is ditched, I'm afraid I'll have to reorganise a lot of software here at the studio, that is solely dependant not on Python, but on .NET. Since without IPy, .NET isn't of any use for us here. We don't use VB or C# or anything else similar. I hope Microsoft will continue to actively develop IronPython, though. Luk?? Dub?da Director [T] +420 602 444 164 duber studio(tm) [M] info at duber.cz [W] http://www.duber.cz [A] R.A.Dvorsk?ho 601, Praha 10 [A] 10900, Czech Republic, Europe On 18.8.2010 19:41, Max Yaffe wrote: > I've been reading the buzz around Microsoft's reduced commitment to Iron* > languages and wondering if I should rethink my own commitment to IronPython. > To fill you in, I'm a designer of instruments and software for scientific > data acquisition and analysis. My current software uses a dynamic language > for scripting in a Win32 based framework program for acquisition and VBA > scripting in a VB program for analysis. We decided to rewrite the whole > thing in C#+.Net4+IronPython. > > On stackoverflow, someone asked about using Iron* vs PowerShell for > scripting in a C# application in light of Microsoft's changing committment. > This was my answer: >> I'm in a similar position. >> I decided to use IronPython scripting but ever since I saw Anders > Hejlsberg's >> talk "The Future of C#", I've had a feeling IronPython was doomed. >> >> It was in Microsoft's interest to get the DLR developed but they > ultimately >> want us to use tools and languages they control. After all, aren't you > using >> C# and not Java? So what will a Microsoft dynamic language look like? How >> about dynamic, interpreted C# (Iron C#)? Hejlsberg's talk made it clear it > >> isn't that far away. He even had a console window with a REPL interface. >> That said, there's always a possibility for Iron VB. Talk about closing > the >> loop. >> >> On the plus side for us programmers, Iron C# also solves another problem > that >> I'm having trouble with -- the existence of two parallel object > environments, >> one of .Net objects, one of Python objects. It takes work to get from one > to >> the other. I assume an Iron C# would utilize the .Net class structure. >> >> My advice: Stick with Iron Python and .Net classes. When Iron VB or Iron > C# >> happens, it'll be a quick, maybe automatic, language translation. Besides, > >> if enough of us use IronPython, Microsoft may change their mindset. > > So my question to you is a) am I thinking correctly about the future of > IronPython, and 2) if not IronPython, what scripting language should I be > considering for a .Net C# application? I should let you know I'm also > considering switching to Qt/PyQt/Cpython. > > Thanks for your input. > Max > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From josh at globalherald.net Wed Aug 18 20:53:17 2010 From: josh at globalherald.net (Joshua Kramer) Date: Wed, 18 Aug 2010 14:53:17 -0400 (EDT) Subject: [IronPython] Iron VB?? In-Reply-To: References: Message-ID: >> That said, there's always a possibility for Iron VB. Talk about closing Wow. Iron VB? They shoud just call it Microsoft Lead: toxic, heavy, and useless for making anything except those things that destroy other things (bullets, or VB Applications). -- ----- http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) From catherine.devlin at gmail.com Wed Aug 18 22:40:19 2010 From: catherine.devlin at gmail.com (Catherine Devlin) Date: Wed, 18 Aug 2010 16:40:19 -0400 Subject: [IronPython] If not IronPython, what? In-Reply-To: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: On Wed, Aug 18, 2010 at 1:41 PM, Max Yaffe wrote: > I've been reading the buzz around Microsoft's reduced commitment to Iron* > languages and wondering if I should rethink my own commitment to > IronPython. > I think you're panicking prematurely. It sounds like the IronRuby team is down to one person, and the IronPython team is likely to indirectly suffer (though I haven't heard anything about decreasing headcount there.) Even if that's a permanent reduction in Microsoft's commitment and not a quirk of office politics or recession economics, that's a long, long way from "IronPython is dead". Consider: CPython has never had a single funded Microsoft employee working on it, and yet somehow it gets by. :) Even Guido is only working half his Google hours on CPython, you know, and there have been periods when not a single human being, anywhere, was being paid by their employer to develop CPython - and yet it has snowballed forward to the present day. Jython had a single Sun-funded employee working on it for roughly 2008-2009, I think - that's all it's ever had. It's nice if companies will hire full-time employees to work on Python implementations, but it's also an unusual luxury, and not at all the normal course of things, much less a prerequisite. And anyway, the IronPython team is still there. This probably does mean we can give up hope of seeing Python in the main Visual Studio distribution, which is a big fat "drat!" as far as Python evangelism goes. But I presume you already have a toolset that satisfies you, so it's not an issue for your team. Anyway, best of luck! -- - Catherine -------------- next part -------------- An HTML attachment was scrubbed... URL: From yngipy at gmail.com Thu Aug 19 12:23:41 2010 From: yngipy at gmail.com (yngipy hernan) Date: Thu, 19 Aug 2010 05:23:41 -0500 Subject: [IronPython] Chasing memory leak in IronPython scripts In-Reply-To: References: <4C6B7D68.7040804@bakalari.cz> Message-ID: Thanks for the input Dino. I will to try to track GC Heap. In the meantime, I tried -X:MTA and got this error: TypeError: Specified cast is not valid. Works fine without -X:MTA switch. -Yngipy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Aug 19 21:34:16 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 19 Aug 2010 19:34:16 +0000 Subject: [IronPython] Chasing memory leak in IronPython scripts In-Reply-To: References: <4C6B7D68.7040804@bakalari.cz> Message-ID: Weird, is there a stack trace? Could you run w/ -X:ExceptionDetail to get the C# stack trace? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of yngipy hernan Sent: Thursday, August 19, 2010 3:24 AM To: Discussion of IronPython Subject: Re: [IronPython] Chasing memory leak in IronPython scripts Thanks for the input Dino. I will to try to track GC Heap. In the meantime, I tried -X:MTA and got this error: TypeError: Specified cast is not valid. Works fine without -X:MTA switch. -Yngipy -------------- next part -------------- An HTML attachment was scrubbed... URL: From yngipy at gmail.com Fri Aug 20 06:06:42 2010 From: yngipy at gmail.com (yngipy hernan) Date: Thu, 19 Aug 2010 23:06:42 -0500 Subject: [IronPython] Chasing memory leak in IronPython scripts In-Reply-To: References: <4C6B7D68.7040804@bakalari.cz> Message-ID: RE: Weird, is there a stack trace? None. RE: Could you run w/ -X:ExceptionDetail to get the C# stack trace? Here you go... D:\>ipy -X:MTA -X:ExceptionDetail stressopc.py Specified cast is not valid. at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal( at Microsoft.Scripting.ComInterop.ComRuntimeHelpers.CheckThrowExceptio essage) at CallSite.Target(Closure , CallSite , Object , Object , Object ) at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](Cal at CallSite.Target(Closure , CallSite , Object , Object , Object ) at CallSite.Target(Closure , CallSite , CodeContext , Object , Object at IronPython.Compiler.Ast.CallExpression.Invoke2Instruction.Run(Inter at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame fr at Microsoft.Scripting.Interpreter.LightLambda.Run3[T0,T1,T2,TRet](T0 at IronPython.Compiler.PythonCallTargets.OriginalCallTarget2(PythonFun at IronPython.Runtime.PythonFunction.FunctionCaller`2.Call2(CallSite s at System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet]( at IronPython.Runtime.PythonFunction.FunctionCaller`2.Default1Call2(Ca 1) at CallSite.Target(Closure , CallSite , CodeContext , Object , Object at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](Cal at CallSite.Target(Closure , CallSite , CodeContext , Object , Object at IronPython.Compiler.Ast.CallExpression.Invoke1Instruction.Run(Inter at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame fr at Microsoft.Scripting.Interpreter.LightLambda.Run1[T0,TRet](T0 arg0) at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope) at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope) at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName) at IronPython.Hosting.PythonCommandLine.RunFile(String fileName) TypeError: Specified cast is not valid. This is where it fails: > OPCDotNetAutomation.OPCItem.Read(self.m_opc_item,DEVICE_READ, self.val, > self.tmp, self.tmp) Where: OPCDotNetAutomation is an interop namespace OPCItem - i think this is an interface .Read - COM method As you may have noticed, I am using unbound class to call .Read method of OPCItem interface(class?). Regards, Yngipy On Thu, Aug 19, 2010 at 2:34 PM, Dino Viehland wrote: > Weird, is there a stack trace? Could you run w/ -X:ExceptionDetail to > get the C# stack trace? > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *yngipy hernan > *Sent:* Thursday, August 19, 2010 3:24 AM > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Chasing memory leak in IronPython scripts > > > > Thanks for the input Dino. I will to try to track GC Heap. > > > > In the meantime, I tried -X:MTA and got this error: > > > > TypeError: Specified cast is not valid. > > > > Works fine without -X:MTA switch. > > > > -Yngipy > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustaq2001 at gmail.com Fri Aug 20 14:15:56 2010 From: mustaq2001 at gmail.com (mohammad mustaq) Date: Fri, 20 Aug 2010 17:45:56 +0530 Subject: [IronPython] "GetSearchPaths" does not return the default directories when run in a new Appdomain Message-ID: Hi, When I create a python engine in a new Appdomain the "GetSearchPaths" method return only the current directory. In default domain it returns "Lib" as well as "Dll" directory in IronPython 2.6.1. Is there a way to get these search paths while the engine is created in a new Appdomain. The reason being that the domain manager of the new Appdomain does not have any information regarding the "EntryAssembly". Is there a way to get the data in the Host's domain manager to the new Appdomain's domain manager. I have provided a code illustrating this. using System; using Microsoft.Scripting; using IronPython.Hosting; using Microsoft.Scripting.Hosting; using System.Runtime.Remoting; using System.Runtime.Remoting.Lifetime; class Foo { public static void Main(string[] args) { AppDomain ad = AppDomain.CreateDomain("foo"); ScriptEngine engine = Python.CreateEngine(ad); engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); ScriptSource code = engine.CreateScriptSourceFromString(@" import MbrBase class C(MbrBase): def Test_C(self, log): print 0 a = C() ", SourceCodeKind.Statements); ScriptScope scope = engine.CreateScope(); code.Execute(scope); Console.WriteLine("Trying to do it... {0}", AppDomain.CurrentDomain.Id); MbrBase mbr = (MbrBase)scope.GetVariable("a"); string isSubClassCode = String.Format("issubclass({0},{1})", "C", "MbrBase"); ScriptSource script = engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression); ICollection paths = engine.GetSearchPaths(); // It returns only current directory. bool result = (bool)script.Execute(scope); if (result == true) { ObjectOperations ops = engine.Operations; ObjectHandle subClass = scope.GetVariableHandle("C"); // get back a handle ObjectHandle instance = ops.Call(subClass, new ObjectHandle[0]); // invoke the handle to create an instance mbr = instance.Unwrap() as MbrBase; // now we know we have an MBR and we can unwrap it to our local side ObjectHandle temp = ops.GetMember(instance, "Test_C"); object log = null; ops.Call(temp, log); } mbr.DoItVirtually(); mbr.DoIt(); Console.ReadKey(); } } public class MbrBase : MarshalByRefObject { public virtual void DoItVirtually() { Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id); } public void DoIt() { Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); } } thanks, Mustaq From merllab at microsoft.com Fri Aug 20 17:39:34 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Fri, 20 Aug 2010 08:39:34 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <5747660e-47ad-47ed-a2c3-e003f939668f@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/75971. MODIFIED SOURCES $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/IronStudioCore/Repl/AutoIndent.cs From dinov at microsoft.com Fri Aug 20 20:28:51 2010 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 20 Aug 2010 18:28:51 +0000 Subject: [IronPython] "GetSearchPaths" does not return the default directories when run in a new Appdomain In-Reply-To: References: Message-ID: You can manually provide the search paths: Dictionary options = new Dictionary(); options["SearchPaths"] = new [] { ".", "C:\\SomeDirectory\\DLLs", "C:\\SomeDirectory\\Libs" }; ScriptEngine engine = Python.CreateEngine(ad, options); I don't know of a way to set the entry assembly other than via starting an .EXE Normally. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of mohammad mustaq > Sent: Friday, August 20, 2010 5:16 AM > To: Discussion of IronPython > Subject: [IronPython] "GetSearchPaths" does not return the default directories > when run in a new Appdomain > > Hi, > > When I create a python engine in a new Appdomain the "GetSearchPaths" > method return only the current directory. In default domain it returns > "Lib" as well as "Dll" directory in IronPython 2.6.1. Is there a way > to get these search paths while the engine is created in a new > Appdomain. > > The reason being that the domain manager of the new Appdomain does not > have any information regarding the "EntryAssembly". Is there a way to > get the data in the Host's domain manager to the new Appdomain's > domain manager. I have provided a code illustrating this. > > > using System; > using Microsoft.Scripting; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > using System.Runtime.Remoting; > using System.Runtime.Remoting.Lifetime; > > class Foo > { > public static void Main(string[] args) > { > AppDomain ad = AppDomain.CreateDomain("foo"); > ScriptEngine engine = Python.CreateEngine(ad); > engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly); > > ScriptSource code = engine.CreateScriptSourceFromString(@" > import MbrBase > class C(MbrBase): > def Test_C(self, log): > print 0 > a = C() > ", SourceCodeKind.Statements); > > ScriptScope scope = engine.CreateScope(); > > code.Execute(scope); > > Console.WriteLine("Trying to do it... {0}", > AppDomain.CurrentDomain.Id); > MbrBase mbr = (MbrBase)scope.GetVariable("a"); > > string isSubClassCode = String.Format("issubclass({0},{1})", > "C", "MbrBase"); > ScriptSource script = > engine.CreateScriptSourceFromString(isSubClassCode, > SourceCodeKind.Expression); > > ICollection paths = engine.GetSearchPaths(); // It > returns only current directory. > > bool result = (bool)script.Execute(scope); > > if (result == true) > { > ObjectOperations ops = engine.Operations; > ObjectHandle subClass = scope.GetVariableHandle("C"); > // get back a handle > ObjectHandle instance = ops.Call(subClass, new > ObjectHandle[0]); // invoke the handle to create an instance > mbr = instance.Unwrap() as MbrBase; // now we know we > have an MBR and we can unwrap it to our local side > > ObjectHandle temp = ops.GetMember(instance, "Test_C"); > object log = null; > ops.Call(temp, log); > } > > mbr.DoItVirtually(); > mbr.DoIt(); > Console.ReadKey(); > } > } > > public class MbrBase : MarshalByRefObject > { > public virtual void DoItVirtually() > { > Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id); > } > > public void DoIt() > { > Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id); > } > } > > thanks, > Mustaq > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From igorfier at hotmail.com Sat Aug 21 13:33:08 2010 From: igorfier at hotmail.com (igorfier at hotmail.com) Date: Sat, 21 Aug 2010 08:33:08 -0300 Subject: [IronPython] set more search paths Message-ID: Hello all, I have been working around to find a way to add more search paths to the IronPython compiler, as I work with a module which only installs inside Python?s directories. After following some examples around the web, I came into the following snippet to call a script in a C# host app: // C# code to call the script private ScriptEngine m_engine = Python.CreateEngine(); private void CallPythonScript() { try { var scope = m_engine.Runtime.CreateScope(); ScriptSource src = m_engine.CreateScriptSourceFromFile("C:\\TestIronPython.py"); string res = src.Execute(); textBox1.Text = res.ToString(); } catch(Exception e) { MessageBox.Show(e.Message); } } // # Python script # appends to PYTHONPATH the location of the visa module import sys sys.path.append(r'C:\Python27\lib') sys.path.append(r'C:\Python27\lib\site-packages') import visa a = visa.get_instruments_list(False) # Although it looks quite simple, VS2010 this throws an exception: ?URI formats are not supported? Does anyone know how to overcome this situation? Thank you for any help provided! Igor Fier Dept. of Physics, Condensed Matter UNESP Rio Claro ? Rio Claro-SP, Brazil -------------- next part -------------- An HTML attachment was scrubbed... URL: From avinhan at gmail.com Sat Aug 21 14:02:25 2010 From: avinhan at gmail.com (Aravin) Date: Sat, 21 Aug 2010 17:32:25 +0530 Subject: [IronPython] set more search paths In-Reply-To: References: Message-ID: Hello, You can add search paths to the PythonEngine by using the PythonEngine.SetSearchPaths(...) function. private List m_searchPaths = new List(); m_searchPaths.Add(AppDomain.CurrentDomain.BaseDirectory); m_searchPaths.Add(@"C:\Python27\lib"); ... private ScriptEngine m_engine = Python.CreateEngine(); m_engine.SetSearchPaths(m_searchPaths); Hope this helps. Regards, Aravin On Sat, Aug 21, 2010 at 5:03 PM, wrote: > Hello all, > > I have been working around to find a way to add more search paths to the > IronPython compiler, as I work with a module which only installs inside > Python?s directories. > After following some examples around the web, I came into the following > snippet to call a script in a C# host app: > > // C# code to call the script > private ScriptEngine m_engine = Python.CreateEngine(); > > private void CallPythonScript() { > try > { > var scope = m_engine.Runtime.CreateScope(); > ScriptSource src = > m_engine.CreateScriptSourceFromFile("C:\\TestIronPython.py"); > string res = src.Execute(); > textBox1.Text = res.ToString(); > } > catch(Exception e) > { > MessageBox.Show(e.Message); > } > } > // > > # Python script > # appends to PYTHONPATH the location of the visa module > import sys > sys.path.append(r'C:\Python27\lib') > sys.path.append(r'C:\Python27\lib\site-packages') > import visa > > a = visa.get_instruments_list(False) > # > > Although it looks quite simple, VS2010 this throws an exception: > ?URI formats are not supported? > > Does anyone know how to overcome this situation? > > Thank you for any help provided! > > Igor Fier > Dept. of Physics, Condensed Matter > UNESP Rio Claro ? Rio Claro-SP, Brazil > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebaurbanski at gmail.com Sat Aug 21 19:33:15 2010 From: sebaurbanski at gmail.com (Sebastian Urbanski) Date: Sat, 21 Aug 2010 14:33:15 -0300 Subject: [IronPython] Help me IronPython + pybluez + VBNET Message-ID: Hello, i'm a student from Argentina I am developing an application that send and receive SMS messages. This works fine in Python + Pybluez, but when i want to execute this code from VBNET, i have problems. Ironpython can't resolve the bluetooth import I am using NET 2008, python 2.6, Iron python 2.6 and PyBluez-0.18.win32-py2.6.exe Here i have a testing class "HelloWorl.py" to try to import package bluetooth. The error result in NET is "global name 'discover_devices' is not defined" import clr import sys sys.path.append(r"C:\Python26\Lib") sys.path.append(r"C:\Python26\Lib\site-packages") import bluetooth import select clr.AddReference('prueba') from prueba import HelloWorldVB class HelloWorldIronPython(HelloWorldVB): def HelloWorld(self, name): return "Hello '" + name + "' from IronPython" Bluetooth's package is installed in the following path: C:\Python26\Lib\site-packages\bluetooth I founded the function discover_devices and it is in bluez.py If i try to import directly the bluez.py i have another error. Ironpython not found the _bluetooth import. import sys import struct import binascii from btcommon import * import _bluetooth as _bt import array import fcntl Here my code for NET (solutions name is "prueba"): Private Sub Button1_Click(ByVal sender As System.Object, ByVal e AsSystem.EventArgs) Handles Button1.Click Dim helloWorld As New HelloWorldVB() MsgBox(helloWorld.HelloWorld("Maurice")) Dim runtime As ScriptRuntime = IronPython.Hosting.Python.CreateEngine.Runtime Dim scope As ScriptScope = runtime.ExecuteFile("HelloWorld.py") Dim pythonType As PythonType = scope.GetVariable(Of PythonType)( "HelloWorldIronPython") helloWorld = CType(runtime.Operations.Invoke(pythonType), HelloWorldVB) MsgBox(helloWorld.HelloWorld("Maurice")) End Sub Public Class HelloWorldVB Public Overridable Function HelloWorld(ByVal name As String) As String Return String.Format("Hello '{0}' from Visual Basic", name) End Function End Class Any idea to import correctly the package bluetooth???? Thanks!!! Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Sun Aug 22 20:17:11 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Sun, 22 Aug 2010 20:17:11 +0200 Subject: [IronPython] Help me IronPython + pybluez + VBNET In-Reply-To: References: Message-ID: <4C7169A7.1070106@bakalari.cz> I guess Pybluez is not pure Python module and uses some C code, so to make it work in IronPython, try IronClad: http://code.google.com/p/ironclad/ -- -- Luk?s( On 21.8.2010 19:33, Sebastian Urbanski wrote: > Hello, i'm a student from Argentina > I am developing an application that send and receive SMS messages. > This works fine in Python + Pybluez, but when i want to execute this > code from VBNET, i have problems. Ironpython can't resolve > the bluetooth import > I am using NET 2008, python 2.6, Iron python 2.6 and > PyBluez-0.18.win32-py2.6.exe > Here i have a testing class "HelloWorl.py" to try to import package > bluetooth. The error result in NET is "global name 'discover_devices' > is not defined" > import clr > import sys > sys.path.append(r"C:\Python26\Lib") > sys.path.append(r"C:\Python26\Lib\site-packages") > import bluetooth > import select > clr.AddReference('prueba') > from prueba import HelloWorldVB > class HelloWorldIronPython(HelloWorldVB): > def HelloWorld(self, name): > return "Hello '" + name + "' from IronPython" > Bluetooth's package is installed in the following path: > C:\Python26\Lib\site-packages\bluetooth > I founded the function discover_devices and it is in bluez.py > If i try to import directly the bluez.py i have another error. > Ironpython not found the _bluetooth import. > import sys > import struct > import binascii > from btcommon import * > import _bluetooth as _bt > import array > import fcntl > Here my code for NET (solutions name is "prueba"): > > Private > > Sub Button1_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles Button1.Click Dim helloWorld As New > HelloWorldVB() > > MsgBox(helloWorld.HelloWorld( > > "Maurice")) Dim runtime As ScriptRuntime = > IronPython.Hosting.Python.CreateEngine.Runtime Dim scope As > ScriptScope = runtime.ExecuteFile("HelloWorld.py") Dim pythonType As > PythonType = scope.GetVariable(Of PythonType)("HelloWorldIronPython") > > helloWorld = > > CType(runtime.Operations.Invoke(pythonType), HelloWorldVB) > > MsgBox(helloWorld.HelloWorld( > > "Maurice")) End Sub > > Public > > Class HelloWorldVB Public Overridable Function HelloWorld(ByVal name > As String) As String Return String.Format("Hello '{0}' from Visual > Basic", name) End Function > > End > > Class > Any idea to import correctly the package bluetooth???? > Thanks!!! > Sebastian > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Sun Aug 22 20:25:02 2010 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Sun, 22 Aug 2010 20:25:02 +0200 Subject: [IronPython] Hosting IronPython in Silverlight - background loading In-Reply-To: References: <4C6B01EC.2040706@bakalari.cz> <4C6B8A68.8070901@bakalari.cz> Message-ID: <4C716B7E.4000307@bakalari.cz> I've entered the issue on tracker: http://ironpython.codeplex.com/workitem/28635 -- -- Luk?? On 18.8.2010 15:44, Jimmy Schementi wrote: > Lukas, this is the bug in Microsoft.Scripting.Silverlight. Because you > do "setup.HostType = > typeof(Microsoft.Scripting.Silverlight.BrowserScriptHost)", all > file-system lookups (like looking for a module) go through that type. > > ~Jimmy > > > On Wed, Aug 18, 2010 at 3:23 AM, Lukas Cenovsky > wrote: > > Looks like there is a bug in DynamicEngine. When I tried the old > way, it works: > > private void UserControl_Loaded(object sender, RoutedEventArgs ev) > { > IPloader = new BackgroundWorker(); > IPloader.DoWork += new DoWorkEventHandler((s, e) => > { > ScriptRuntimeSetup setup = new ScriptRuntimeSetup(); > > setup.LanguageSetups.Add(Python.CreateLanguageSetup(null)); > setup.HostType = > typeof(Microsoft.Scripting.Silverlight.BrowserScriptHost); > setup.DebugMode = true; > runtime = new ScriptRuntime(setup); > engine = Python.GetEngine(runtime); > foreach (string str in new string[] { "mscorlib", > "System", "System.Windows", "System.Windows.Browser", "System.Net" }) > { > > runtime.LoadAssembly(runtime.Host.PlatformAdaptationLayer.LoadAssembly(str)); > } > // engine.Execute("import imptest"); --this does not work > > } > ); > IPloader.RunWorkerCompleted += new > RunWorkerCompletedEventHandler((s, e) => > { > this.textBlock1.Text = "IronPython loaded"; > } > ); > IPloader.RunWorkerAsync(); > } > > What does not work is importing modules in the background thread > (commented line). It throws the following exception: > > System.InvalidOperationException was unhandled by user code > Message=This operation can only occur on the UI Thread. > StackTrace: > at > Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] > args, Boolean& shouldOptimize) > at > IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite > site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 > arg2, T3 arg3) > at > System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) > at IronPython.Runtime.Importer.Import(CodeContext context, > String fullName, PythonTuple from, Int32 level) > at > IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext > context, String fullName, Int32 level) > at > Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame > frame) > at > Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame > frame) > at > Microsoft.Scripting.Interpreter.LightLambda.Run1[T0,TRet](T0 arg0) > at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope > scope) > at IronPython.Compiler.RuntimeScriptCode.Run() > at Microsoft.Scripting.SourceUnit.Execute() > at Microsoft.Scripting.Hosting.ScriptSource.Execute() > at Microsoft.Scripting.Hosting.ScriptEngine.Execute(String > expression) > > at SLHosting.MainPage.b__0(Object s, > DoWorkEventArgs e) > at > System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) > at System.ComponentModel.BackgroundWorker.OnRun(Object > argument) > InnerException: > > > runtime.ImportModule("imptest"); is similar story so I guess it > cannot be done, right? > > -- > -- Luk?? > > > > On 18.8.2010 5:05, Jimmy Schementi wrote: >> True, but according to his exception stack it never gets there >> ... it throws on the "runtime = >> DynamicEngine.CreateRuntime(true);" line. It throws because >> somewhere in that method it doesn't dispatch to the UI thread as >> you described. Those are the fixes I need to do. >> >> ~Jimmy >> >> >> 2010/8/17 Dave Curylo > >> >> Lukas, >> >> I think the problem is the RunWorkerCompleted handler trying >> to update the UI. Wrap calls from a background thread to >> update UI controls in something like this so the Dispatcher >> updates any controls on the UI thread: >> >> this.Dispatcher.BeginInvoke(() => >> { >> this.textBlock1.Text = "IronPython loaded"; >> }); >> >> Hope that helps. >> >> -Dave >> >> 2010/8/17 Lukas Cenovsky > > >> >> Hi all, >> is it possible to load IronPython engine in the >> background thread in Silverlight? >> >> I tried to load it via BackgroundWorker: >> >> private void UserControl_Loaded(object sender, >> RoutedEventArgs ev) >> { >> IPloader = new BackgroundWorker(); >> IPloader.DoWork += new DoWorkEventHandler((s, e) => >> { >> runtime = DynamicEngine.CreateRuntime(true); >> // debug mode true >> engine = runtime.GetEngine("python"); >> } >> ); >> IPloader.RunWorkerCompleted += new >> RunWorkerCompletedEventHandler((s, e) => >> { >> this.textBlock1.Text = "IronPython loaded"; >> } >> ); >> IPloader.RunWorkerAsync(); >> } >> >> It fails with the following exception: >> >> System.UnauthorizedAccessException was unhandled by user code >> Message=Invalid cross-thread access. >> StackTrace: >> at MS.Internal.XcpImports.CheckThread() >> at >> System.Windows.DependencyObject.GetValueInternal(DependencyProperty >> dp) >> at System.Windows.Deployment.get_Parts() >> at >> Microsoft.Scripting.Silverlight.DynamicAppManifest.AssemblyParts() >> at >> Microsoft.Scripting.Silverlight.DynamicAppManifest..ctor() >> at >> Microsoft.Scripting.Silverlight.DynamicEngine.CreateLangConfig() >> at >> Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntimeSetup(Boolean >> debugMode) >> at >> Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime(Boolean >> debugMode) >> at >> SLHosting.MainPage.b__0(Object s, >> DoWorkEventArgs e) >> at >> System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs >> e) >> at >> System.ComponentModel.BackgroundWorker.OnRun(Object argument) >> InnerException: >> >> Thanks for any advice. >> >> -- >> -- Luk?? >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Sun Aug 22 22:57:07 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Sun, 22 Aug 2010 14:57:07 -0600 Subject: [IronPython] If not IronPython, what? In-Reply-To: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: Sorry for chiming in late. I've been on vacation, and since my "smart" phone runs Windows Mobile, it does not work very well, so I have not kept up on my email. When I first started in this industry, there where two groups of computer users: IBM and everybody else. I was in the "everybody else" group, and developed a deep disrespect for 'Big Blue". There were lots of people who were always willing to believe that anything IBM did was the greatest thing in the world and everything else was trash. "We are an IBM shop" was the excuse for a lot of what looked -- to me -- like mismanagement and waste.. Today IBM has faded into a niche, and Microsoft is the 900 pound gorilla in the computing cage. There are those today who chant "WE ARE A MICROSOFT SHOP" as if it were a mantra embodying all good, and all else is evil. If you work in such a place I am sorry for you. I have worked in such places and I am glad I am out. By all means USE IronPython, it's the best tool in your shop. But let's set the record straight -- at least my humble opinion of the record -- dotNET was a stupid idea to start with. Why invent a new pseudo-machine to compile everything in, when 99% of the world is using the same hardware machine anyway? Pseudo machines were great when 32 K bytes was a large computer, by why now? The "just in time" compiler should be called a "waste my time" compiler. If you think I'm wrong, try running "hello world" in CPython and IronPython and see which one is faster. _Anything_ running on CLR starts up like as sleepy teenager. [And why oh why did they let the sales department stick it with a name which conflicts with an Internet domain? But I digress....] Do I support IronPython? Yes, I do. Because some poor saps are stuck working in "WE ARE A ... SHOP." places. Do I personally use IronPython for production software? Nope! I use CPython -- on Linux where possible and on Windows where necessary. The concept of "scientific data acquisition" using Windows is an oxymoron. * Max: I strongly encourage you to continue to look at alternatives which were _not_ made in Redmond, Washington, USA. If nothing else, the competition pushes Microsoft to continue to improve the quality of their products. IronPython is the greatest thing which has happened in Redmond since NT was shipped. -- Vernon Cole * this e-mail is being written on an Ubuntu Linux box which is also running a closed-loop environmental control system (written in Python) while I type. On Wed, Aug 18, 2010 at 11:41 AM, Max Yaffe wrote: > I've been reading the buzz around Microsoft's reduced commitment to Iron* > languages and wondering if I should rethink my own commitment to > IronPython. > To fill you in, I'm a designer of instruments and software for scientific > data acquisition and analysis. My current software uses a dynamic language > for scripting in a Win32 based framework program for acquisition and VBA > scripting in a VB program for analysis. We decided to rewrite the whole > thing in C#+.Net4+IronPython. > > On stackoverflow, someone asked about using Iron* vs PowerShell for > scripting in a C# application in light of Microsoft's changing committment. > This was my answer: > > I'm in a similar position. > > I decided to use IronPython scripting but ever since I saw Anders > Hejlsberg's > > talk "The Future of C#", I've had a feeling IronPython was doomed. > > > > It was in Microsoft's interest to get the DLR developed but they > ultimately > > want us to use tools and languages they control. After all, aren't you > using > > C# and not Java? So what will a Microsoft dynamic language look like? How > > about dynamic, interpreted C# (Iron C#)? Hejlsberg's talk made it clear > it > > > isn't that far away. He even had a console window with a REPL interface. > > That said, there's always a possibility for Iron VB. Talk about closing > the > > loop. > > > > On the plus side for us programmers, Iron C# also solves another problem > that > > I'm having trouble with -- the existence of two parallel object > environments, > > one of .Net objects, one of Python objects. It takes work to get from one > to > > the other. I assume an Iron C# would utilize the .Net class structure. > > > > My advice: Stick with Iron Python and .Net classes. When Iron VB or Iron > C# > > happens, it'll be a quick, maybe automatic, language translation. > Besides, > > > if enough of us use IronPython, Microsoft may change their mindset. > > So my question to you is a) am I thinking correctly about the future of > IronPython, and 2) if not IronPython, what scripting language should I be > considering for a .Net C# application? I should let you know I'm also > considering switching to Qt/PyQt/Cpython. > > Thanks for your input. > Max > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loocas at duber.cz Sun Aug 22 23:37:50 2010 From: loocas at duber.cz (=?UTF-8?B?THVrw6HFoSBEdWLEm2Rh?=) Date: Sun, 22 Aug 2010 23:37:50 +0200 Subject: [IronPython] If not IronPython, what? In-Reply-To: References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: <4C7198AE.6050805@duber.cz> Very nicely said, Vernon, however, there are also users that simply don't have a choice. We're using a commercially available DCC software that doesn't support Python, however, it does support .NET. So, the only way to get Python in such an environment is IronPython. If IPy dies, our pipeline dies with it. So, to some, it's simply not a matter of choice, unfortunately. Luk?? Dub?da Director [T] +420 602 444 164 duber studio(tm) [M] info at duber.cz [W] http://www.duber.cz [A] R.A.Dvorsk?ho 601, Praha 10 [A] 10900, Czech Republic, Europe On 22.8.2010 22:57, Vernon Cole wrote: > Sorry for chiming in late. I've been on vacation, and since my "smart" > phone runs Windows Mobile, it does not work very well, so I have not > kept up on my email. > > When I first started in this industry, there where two groups of > computer users: IBM and everybody else. I was in the "everybody else" > group, and developed a deep disrespect for 'Big Blue". There were lots > of people who were always willing to believe that anything IBM did was > the greatest thing in the world and everything else was trash. "We are > an IBM shop" was the excuse for a lot of what looked -- to me -- like > mismanagement and waste.. > > Today IBM has faded into a niche, and Microsoft is the 900 pound gorilla > in the computing cage. There are those today who chant "WE ARE A > MICROSOFT SHOP" as if it were a mantra embodying all good, and all else > is evil. If you work in such a place I am sorry for you. I have worked > in such places and I am glad I am out. By all means USE IronPython, it's > the best tool in your shop. > > But let's set the record straight -- at least my humble opinion of the > record -- dotNET was a stupid idea to start with. Why invent a new > pseudo-machine to compile everything in, when 99% of the world is using > the same hardware machine anyway? Pseudo machines were great when 32 K > bytes was a large computer, by why now? The "just in time" compiler > should be called a "waste my time" compiler. If you think I'm wrong, > try running "hello world" in CPython and IronPython and see which one is > faster. _Anything_ running on CLR starts up like as sleepy teenager. > [And why oh why did they let the sales department stick it with a name > which conflicts with an Internet domain? But I digress....] > > Do I support IronPython? Yes, I do. Because some poor saps are stuck > working in "WE ARE A ... SHOP." places. Do I personally use IronPython > for production software? Nope! I use CPython -- on Linux where possible > and on Windows where necessary. The concept of "scientific data > acquisition" using Windows is an oxymoron. * > > Max: > I strongly encourage you to continue to look at alternatives which > were _not_ made in Redmond, Washington, USA. If nothing else, the > competition pushes Microsoft to continue to improve the quality of their > products. IronPython is the greatest thing which has happened in > Redmond since NT was shipped. > -- > Vernon Cole > > * this e-mail is being written on an Ubuntu Linux box which is also > running a closed-loop environmental control system (written in Python) > while I type. > > On Wed, Aug 18, 2010 at 11:41 AM, Max Yaffe > wrote: > > I've been reading the buzz around Microsoft's reduced commitment to > Iron* > languages and wondering if I should rethink my own commitment to > IronPython. > To fill you in, I'm a designer of instruments and software for > scientific > data acquisition and analysis. My current software uses a dynamic > language > for scripting in a Win32 based framework program for acquisition and VBA > scripting in a VB program for analysis. We decided to rewrite the whole > thing in C#+.Net4+IronPython. > > On stackoverflow, someone asked about using Iron* vs PowerShell for > scripting in a C# application in light of Microsoft's changing > committment. > This was my answer: > > I'm in a similar position. > > I decided to use IronPython scripting but ever since I saw Anders > Hejlsberg's > > talk "The Future of C#", I've had a feeling IronPython was doomed. > > > > It was in Microsoft's interest to get the DLR developed but they > ultimately > > want us to use tools and languages they control. After all, > aren't you > using > > C# and not Java? So what will a Microsoft dynamic language look > like? How > > about dynamic, interpreted C# (Iron C#)? Hejlsberg's talk made it > clear it > > > isn't that far away. He even had a console window with a REPL > interface. > > That said, there's always a possibility for Iron VB. Talk about > closing > the > > loop. > > > > On the plus side for us programmers, Iron C# also solves another > problem > that > > I'm having trouble with -- the existence of two parallel object > environments, > > one of .Net objects, one of Python objects. It takes work to get > from one > to > > the other. I assume an Iron C# would utilize the .Net class > structure. > > > > My advice: Stick with Iron Python and .Net classes. When Iron VB > or Iron > C# > > happens, it'll be a quick, maybe automatic, language translation. > Besides, > > > if enough of us use IronPython, Microsoft may change their mindset. > > So my question to you is a) am I thinking correctly about the future of > IronPython, and 2) if not IronPython, what scripting language should > I be > considering for a .Net C# application? I should let you know I'm also > considering switching to Qt/PyQt/Cpython. > > Thanks for your input. > Max > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From tristanz at gmail.com Mon Aug 23 00:22:46 2010 From: tristanz at gmail.com (Tristan Zajonc) Date: Sun, 22 Aug 2010 18:22:46 -0400 Subject: [IronPython] If not IronPython, what? In-Reply-To: References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: The popularity of the JVM and the CLR suggest not everybody agrees with your assessment. IronPython provides a compelling interoperability story for some applications. I use IronPython and F# on Mac and Linux, so I'm not certain where the Windows requirement comes from. I happily use CPython as well. I do encourage Microsoft to clarify its position on DLR and Iron* support sooner than later. Given the dominance of dynamic languages such as Python, Perl, R, and Matlab as the glue language in science, I'm skeptical that Microsoft's new technical computing initiative will succeed without some dynamic language support. I'm hopeful that the NumPy announcement means IronPython will get support as an infrastructure component in the technical computing initiative. Tristan On Sun, Aug 22, 2010 at 4:57 PM, Vernon Cole wrote: > Sorry for chiming in late. I've been on vacation, and since my "smart" > phone runs Windows Mobile, it does not work very well, so I have not kept up > on my email. > > When I first started in this industry, there where two groups of computer > users: IBM and everybody else. I was in the "everybody else" group, and > developed a deep disrespect for 'Big Blue". There were lots of people who > were always willing to believe that anything IBM did was the greatest thing > in the world and everything else was trash. "We are an IBM shop" was the > excuse for a lot of what looked -- to me -- like mismanagement and waste.. > > Today IBM has faded into a niche, and Microsoft is the 900 pound gorilla in > the computing cage. There are those today who chant "WE ARE A MICROSOFT > SHOP" as if it were a mantra embodying all good, and all else is evil. If > you work in such a place I am sorry for you. I have worked in such places > and I am glad I am out. By all means USE IronPython, it's the best tool in > your shop. > > But let's set the record straight -- at least my humble opinion of the > record -- dotNET was a stupid idea to start with. Why invent a new > pseudo-machine to compile everything in, when 99% of the world is using the > same hardware machine anyway? Pseudo machines were great when 32 K bytes > was a large computer, by why now? The "just in time" compiler should be > called a "waste my time" compiler. If you think I'm wrong, try running > "hello world" in CPython and IronPython and see which one is faster. > _Anything_ running on CLR starts up like as sleepy teenager. [And why oh > why did they let the sales department stick it with a name which conflicts > with an Internet domain? But I digress....] > > Do I support IronPython? Yes, I do. Because some poor saps are stuck > working in "WE ARE A ... SHOP." places. Do I personally use IronPython for > production software? Nope! I use CPython -- on Linux where possible and on > Windows where necessary. The concept of "scientific data acquisition" using > Windows is an oxymoron. * > > Max: > I strongly encourage you to continue to look at alternatives which were > _not_ made in Redmond, Washington, USA. If nothing else, the competition > pushes Microsoft to continue to improve the quality of their products. > IronPython is the greatest thing which has happened in Redmond since NT was > shipped. > -- > Vernon Cole > > * this e-mail is being written on an Ubuntu Linux box which is also running > a closed-loop environmental control system (written in Python) while I type. > > > On Wed, Aug 18, 2010 at 11:41 AM, Max Yaffe wrote: > >> I've been reading the buzz around Microsoft's reduced commitment to Iron* >> languages and wondering if I should rethink my own commitment to >> IronPython. >> To fill you in, I'm a designer of instruments and software for scientific >> data acquisition and analysis. My current software uses a dynamic >> language >> for scripting in a Win32 based framework program for acquisition and VBA >> scripting in a VB program for analysis. We decided to rewrite the whole >> thing in C#+.Net4+IronPython. >> >> On stackoverflow, someone asked about using Iron* vs PowerShell for >> scripting in a C# application in light of Microsoft's changing >> committment. >> This was my answer: >> > I'm in a similar position. >> > I decided to use IronPython scripting but ever since I saw Anders >> Hejlsberg's >> > talk "The Future of C#", I've had a feeling IronPython was doomed. >> > >> > It was in Microsoft's interest to get the DLR developed but they >> ultimately >> > want us to use tools and languages they control. After all, aren't you >> using >> > C# and not Java? So what will a Microsoft dynamic language look like? >> How >> > about dynamic, interpreted C# (Iron C#)? Hejlsberg's talk made it clear >> it >> >> > isn't that far away. He even had a console window with a REPL interface. >> > That said, there's always a possibility for Iron VB. Talk about closing >> the >> > loop. >> > >> > On the plus side for us programmers, Iron C# also solves another problem >> that >> > I'm having trouble with -- the existence of two parallel object >> environments, >> > one of .Net objects, one of Python objects. It takes work to get from >> one >> to >> > the other. I assume an Iron C# would utilize the .Net class structure. >> > >> > My advice: Stick with Iron Python and .Net classes. When Iron VB or Iron >> C# >> > happens, it'll be a quick, maybe automatic, language translation. >> Besides, >> >> > if enough of us use IronPython, Microsoft may change their mindset. >> >> So my question to you is a) am I thinking correctly about the future of >> IronPython, and 2) if not IronPython, what scripting language should I be >> considering for a .Net C# application? I should let you know I'm also >> considering switching to Qt/PyQt/Cpython. >> >> Thanks for your input. >> Max >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.brown.bayliss at gmail.com Mon Aug 23 04:51:24 2010 From: r.brown.bayliss at gmail.com (Rob Brown-Bayliss) Date: Mon, 23 Aug 2010 14:51:24 +1200 Subject: [IronPython] If not IronPython, what? In-Reply-To: References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: On Mon, Aug 23, 2010 at 10:22 AM, Tristan Zajonc wrote: > The popularity of the JVM and the CLR suggest not everybody agrees with your > assessment. A lot of the 'popularity' comes from people who shouldn't be making the choice. I work for a company where the management think dot net will end poverty, fix global warming and bring world peace while ensuring they grab more of the market than our competition. Every thing has to be dot net to these people, none of whom know what a VM is. It has to be dot net because microsoft sales people tell them so. Fortunately I can use Ironpython because it has the dot net magic. Unfortunately I cant use cpython because it's just not magic. I agree with Vernon, a VM that basically (I know about mono, but it's always going to be playing catch up) only runs on Windows is a stupid idea. But as long as people who don't know what they are talking about are running the show thats how it will be. -- Rob From fuzzyman at voidspace.org.uk Mon Aug 23 10:25:35 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 23 Aug 2010 11:25:35 +0300 Subject: [IronPython] If not IronPython, what? In-Reply-To: References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> Message-ID: <4C72307F.7080807@voidspace.org.uk> On 23/08/2010 05:51, Rob Brown-Bayliss wrote: > On Mon, Aug 23, 2010 at 10:22 AM, Tristan Zajonc wrote: >> The popularity of the JVM and the CLR suggest not everybody agrees with your >> assessment. > A lot of the 'popularity' comes from people who shouldn't be making > the choice. I work for a company where the management think dot net > will end poverty, fix global warming and bring world peace while > ensuring they grab more of the market than our competition. > > Every thing has to be dot net to these people, none of whom know what > a VM is. It has to be dot net because microsoft sales people tell > them so. Well, if languages based on VMs that compile to an intermediate representation first and then interpret bytecode are *bad* then that sends CPython out of the window too... Of course both .NET and the JVM have kick-ass JIT compilers, so maybe it is having a JIT compiler that is bad? That makes CPython good but PyPy and Unladen Swallow bad (along with IronPython and Jython of course). Hmm... The cross-platform story for .NET is not brilliant, with Mono constantly playing catch-up and only just switching away from a leaks-like-hell garbage collector. Other than that the "technical arguments" that have been presented against .NET in this thread are poor. All the best, Michael Foord > Fortunately I can use Ironpython because it has the dot net magic. > Unfortunately I cant use cpython because it's just not magic. > > I agree with Vernon, a VM that basically (I know about mono, but it's > always going to be playing catch up) only runs on Windows is a stupid > idea. But as long as people who don't know what they are talking > about are running the show thats how it will be. > > > -- > > Rob > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ From empirebuilder at gmail.com Mon Aug 23 16:53:45 2010 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Mon, 23 Aug 2010 17:53:45 +0300 Subject: [IronPython] If not IronPython, what? In-Reply-To: <4C72307F.7080807@voidspace.org.uk> References: <51A3B387ACE24FC0AA1E973BE2DBEC30@Gamry.com> <4C72307F.7080807@voidspace.org.uk> Message-ID: Hi all, My firm develops both on CPython(Django) and IronPython (embedded in C# 4.0 applications) and we have no plan to change. So far so good. We use IronPython for the power of its language, not so much for Python libraries. Dody G. On Mon, Aug 23, 2010 at 11:25 AM, Michael Foord wrote: > On 23/08/2010 05:51, Rob Brown-Bayliss wrote: > >> On Mon, Aug 23, 2010 at 10:22 AM, Tristan Zajonc >> wrote: >> >>> The popularity of the JVM and the CLR suggest not everybody agrees with >>> your >>> assessment. >>> >> A lot of the 'popularity' comes from people who shouldn't be making >> the choice. I work for a company where the management think dot net >> will end poverty, fix global warming and bring world peace while >> ensuring they grab more of the market than our competition. >> >> Every thing has to be dot net to these people, none of whom know what >> a VM is. It has to be dot net because microsoft sales people tell >> them so. >> > > Well, if languages based on VMs that compile to an intermediate > representation first and then interpret bytecode are *bad* then that sends > CPython out of the window too... > > Of course both .NET and the JVM have kick-ass JIT compilers, so maybe it is > having a JIT compiler that is bad? That makes CPython good but PyPy and > Unladen Swallow bad (along with IronPython and Jython of course). Hmm... > > The cross-platform story for .NET is not brilliant, with Mono constantly > playing catch-up and only just switching away from a leaks-like-hell garbage > collector. Other than that the "technical arguments" that have been > presented against .NET in this thread are poor. > > All the best, > > Michael Foord > > > Fortunately I can use Ironpython because it has the dot net magic. >> Unfortunately I cant use cpython because it's just not magic. >> >> I agree with Vernon, a VM that basically (I know about mono, but it's >> always going to be playing catch up) only runs on Windows is a stupid >> idea. But as long as people who don't know what they are talking >> about are running the show thats how it will be. >> >> >> -- >> >> Rob >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > -- > http://www.ironpythoninaction.com/ > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebaurbanski at gmail.com Mon Aug 23 17:01:02 2010 From: sebaurbanski at gmail.com (Sebastian Urbanski) Date: Mon, 23 Aug 2010 12:01:02 -0300 Subject: [IronPython] Help me IronPython + pybluez + VBNET In-Reply-To: <4C7169A7.1070106@bakalari.cz> References: <4C7169A7.1070106@bakalari.cz> Message-ID: Thanks for your reply! I tried with Ironclad but I got the same error: IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.1873 Type "help", "copyright", "credits" or "license" for more information. >>> import ironclad >>> import bluetooth Traceback (most recent call last): File "", line 1, in NameError: global name 'discover_devices' is not defined Thanks again! Sebastian 2010/8/22 Lukas Cenovsky > I guess Pybluez is not pure Python module and uses some C code, so to make > it work in IronPython, try IronClad: http://code.google.com/p/ironclad/ > > -- > -- Luk?? > > > > On 21.8.2010 19:33, Sebastian Urbanski wrote: > > Hello, i'm a student from Argentina > > I am developing an application that send and receive SMS messages. > > This works fine in Python + Pybluez, but when i want to execute this code > from VBNET, i have problems. Ironpython can't resolve the bluetooth import > > I am using NET 2008, python 2.6, Iron python 2.6 and > PyBluez-0.18.win32-py2.6.exe > > > Here i have a testing class "HelloWorl.py" to try to import package > bluetooth. The error result in NET is "global name 'discover_devices' is not > defined" > > import clr > import sys > sys.path.append(r"C:\Python26\Lib") > sys.path.append(r"C:\Python26\Lib\site-packages") > import bluetooth > import select > clr.AddReference('prueba') > from prueba import HelloWorldVB > class HelloWorldIronPython(HelloWorldVB): > def HelloWorld(self, name): > return "Hello '" + name + "' from IronPython" > Bluetooth's package is installed in the following path: > C:\Python26\Lib\site-packages\bluetooth > > I founded the function discover_devices and it is in bluez.py > > If i try to import directly the bluez.py i have another error. Ironpython > not found the _bluetooth import. > > import sys > import struct > import binascii > from btcommon import * > import _bluetooth as _bt > import array > import fcntl > > Here my code for NET (solutions name is "prueba"): > > > Private > Sub Button1_Click(ByVal sender As System.Object, ByVal e AsSystem.EventArgs) > Handles Button1.Click Dim helloWorld As New HelloWorldVB() > > MsgBox(helloWorld.HelloWorld( > "Maurice")) Dim runtime As ScriptRuntime = > IronPython.Hosting.Python.CreateEngine.Runtime Dim scope As ScriptScope = > runtime.ExecuteFile("HelloWorld.py") Dim pythonType As PythonType = > scope.GetVariable(Of PythonType)("HelloWorldIronPython") > > helloWorld = > CType(runtime.Operations.Invoke(pythonType), HelloWorldVB) > > MsgBox(helloWorld.HelloWorld( > "Maurice")) End Sub > > > Public > Class HelloWorldVB Public Overridable Function HelloWorld(ByVal name As > String) As String Return String.Format("Hello '{0}' from Visual Basic", > name) End Function > > End > Class > > > Any idea to import correctly the package bluetooth???? > > > Thanks!!! > > > Sebastian > > > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twyatt at ppi.ca Mon Aug 23 17:03:01 2010 From: twyatt at ppi.ca (Tim P. Wyatt) Date: Mon, 23 Aug 2010 08:03:01 -0700 Subject: [IronPython] Tim Wyatt is out of the office Message-ID: I will be out of the office starting 23/08/2010 and will not return until 26/08/2010. I will be reviewing my email less frequently than usual. For urgent matters please contact the Vancouver Help Desk at 1-800-661-7712 (helpdesk at ppi.ca) From stephan.fortelny at rubicon.eu Tue Aug 24 15:54:34 2010 From: stephan.fortelny at rubicon.eu (Fortelny, Stephan) Date: Tue, 24 Aug 2010 13:54:34 +0000 Subject: [IronPython] embedded ironpython in silverlight - class definitions Message-ID: hi there, i'm trying to use ironpython embedded in silverlight there is a tutorial here http://www.voidspace.org.uk/ironpython/silverlight/embedding_ironpython.shtml but it seems that you can not define your own classes. When doing this in a script i get an "MethodAccessException" when accessing "System.RuntimeMethodHandle.get_Value()" somewhere in the ctor of the defined class. This due to Silverlight having no security privileges so does anybody know how to solve this? My code sample http://pastebin.com/7j8iXEAE which basically creates a ironpython script extracting it to a delegate. Then it calls the defined function. IronPython stdout is set to a stream which is used later to set the text of a textbox -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at schementi.com Tue Aug 24 19:44:05 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Tue, 24 Aug 2010 13:44:05 -0400 Subject: [IronPython] embedded ironpython in silverlight - class definitions In-Reply-To: References: Message-ID: When I run that code (with Visual Studio 2010, Silverlight 4, and IronPython 2.7) I get a Python syntax error "unexpected token ", because you don't have a ":" after the __init__ function. When that is corrected, your example works properly. Here's the working example: http://jimmy.schementi.com/silverlight/ipysl-repro20100824.zip. See the Bin\Debug directory ... the HTML file and XAP for the app are in there, which contains the IronPython assemblies. ~Jimmy On Tue, Aug 24, 2010 at 9:54 AM, Fortelny, Stephan < stephan.fortelny at rubicon.eu> wrote: > hi there, > > i'm trying to use ironpython embedded in silverlight > > there is a tutorial here * > http://www.voidspace.org.uk/ironpython/silverlight/embedding_ironpython.shtml > * but it seems that you can not define your own classes. > > When doing this in a script i get an "MethodAccessException" when accessing > "System.RuntimeMethodHandle.get_Value()" somewhere in the ctor of the > defined class. > > This due to Silverlight having no security privileges so does anybody know > how to solve this? > > > > My code sample http://pastebin.com/7j8iXEAE which basically creates a > ironpython script extracting it to a delegate. Then it calls the defined > function. IronPython stdout is set to a stream which is used later to set > the text of a textbox > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 24 19:47:22 2010 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 24 Aug 2010 17:47:22 +0000 Subject: [IronPython] embedded ironpython in silverlight - class definitions In-Reply-To: References: Message-ID: I think this issue is an old version of IronPython. Silverlight 4 included a breaking change which broke IronPython 2.0.2 and maybe 2.6.0. I think we fixed the issues for 2.0.3 and 2.6.1. So the solution should be to use a newer version of IronPython. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jimmy Schementi Sent: Tuesday, August 24, 2010 10:44 AM To: Discussion of IronPython Subject: Re: [IronPython] embedded ironpython in silverlight - class definitions When I run that code (with Visual Studio 2010, Silverlight 4, and IronPython 2.7) I get a Python syntax error "unexpected token ", because you don't have a ":" after the __init__ function. When that is corrected, your example works properly. Here's the working example: http://jimmy.schementi.com/silverlight/ipysl-repro20100824.zip. See the Bin\Debug directory ... the HTML file and XAP for the app are in there, which contains the IronPython assemblies. ~Jimmy On Tue, Aug 24, 2010 at 9:54 AM, Fortelny, Stephan > wrote: hi there, i'm trying to use ironpython embedded in silverlight there is a tutorial here http://www.voidspace.org.uk/ironpython/silverlight/embedding_ironpython.shtml but it seems that you can not define your own classes. When doing this in a script i get an "MethodAccessException" when accessing "System.RuntimeMethodHandle.get_Value()" somewhere in the ctor of the defined class. This due to Silverlight having no security privileges so does anybody know how to solve this? My code sample http://pastebin.com/7j8iXEAE which basically creates a ironpython script extracting it to a delegate. Then it calls the defined function. IronPython stdout is set to a stream which is used later to set the text of a textbox _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From afriza.na at gmail.com Wed Aug 25 03:43:47 2010 From: afriza.na at gmail.com (Afriza N. Arief) Date: Wed, 25 Aug 2010 09:43:47 +0800 Subject: [IronPython] Help me help you: What would you like to see us do with IronRuby? Message-ID: Help me help you: What would you like to see us do with IronRuby? http://twtpoll.com/25yxuj Source: http://twitter.com/shanselman/status/21973813667 -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Wed Aug 25 04:11:47 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 24 Aug 2010 19:11:47 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <9674b18f-0a27-4b7e-a9e3-de16ac6f6dca@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/76397. MODIFIED SOURCES $/IronPython/IronPython_Main/Scripts/Bat/BuildRowan.cmd From merllab at microsoft.com Wed Aug 25 17:48:43 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 25 Aug 2010 08:48:43 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <1e7e61d6-67da-42f8-b5fe-c5fb321d7505@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/76456. MODIFIED SOURCES $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Chiron.csproj $/IronPython/IronPython_Main/Msi/IronStudio/IronStudio.msm.wproj From jimmy at schementi.com Wed Aug 25 17:57:24 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Wed, 25 Aug 2010 11:57:24 -0400 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: <1e7e61d6-67da-42f8-b5fe-c5fb321d7505@tk5-exsmh-c101.redmond.corp.microsoft.com> References: <1e7e61d6-67da-42f8-b5fe-c5fb321d7505@tk5-exsmh-c101.redmond.corp.microsoft.com> Message-ID: How come a Debug/Release configuration was added to Chiron.csproj? ~Jimmy On Wed, Aug 25, 2010 at 11:48 AM, wrote: > This is an automated email letting you know that sources > have recently been pushed out. You can download these newer > sources directly from > http://ironpython.codeplex.com/SourceControl/changeset/view/76456. > > MODIFIED SOURCES > $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Chiron.csproj > $/IronPython/IronPython_Main/Msi/IronStudio/IronStudio.msm.wproj > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Aug 25 18:15:14 2010 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 25 Aug 2010 16:15:14 +0000 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: References: <1e7e61d6-67da-42f8-b5fe-c5fb321d7505@tk5-exsmh-c101.redmond.corp.microsoft.com> Message-ID: So that when we do a build for the MSI it'll get built in the same way that it does for "Silverlight4Release" and "Silverlight4Debug". That lets us just kick off 1 msbuild and get the resulting binaries. I could also look at making us do a separate build for that if necessary but it seems like building it w/ the desktop binaries is fine. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jimmy Schementi Sent: Wednesday, August 25, 2010 8:57 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 CodePlex Source Update How come a Debug/Release configuration was added to Chiron.csproj? ~Jimmy On Wed, Aug 25, 2010 at 11:48 AM, > wrote: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/76456. MODIFIED SOURCES $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Chiron.csproj $/IronPython/IronPython_Main/Msi/IronStudio/IronStudio.msm.wproj _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at schementi.com Wed Aug 25 18:17:09 2010 From: jimmy at schementi.com (Jimmy Schementi) Date: Wed, 25 Aug 2010 12:17:09 -0400 Subject: [IronPython] IronPython 2.6 CodePlex Source Update In-Reply-To: References: <1e7e61d6-67da-42f8-b5fe-c5fb321d7505@tk5-exsmh-c101.redmond.corp.microsoft.com> Message-ID: Ah yes, the VS tools depend on Chiron. Makes sense. ~Jimmy On Wed, Aug 25, 2010 at 12:15 PM, Dino Viehland wrote: > So that when we do a build for the MSI it?ll get built in the same way > that it does for ?Silverlight4Release? and ?Silverlight4Debug?. That lets > us just kick off 1 msbuild and get the resulting binaries. > > > > I could also look at making us do a separate build for that if necessary > but it seems like building it w/ the desktop binaries is fine. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Jimmy Schementi > *Sent:* Wednesday, August 25, 2010 8:57 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] IronPython 2.6 CodePlex Source Update > > > > How come a Debug/Release configuration was added to Chiron.csproj? > ~Jimmy > > On Wed, Aug 25, 2010 at 11:48 AM, wrote: > > This is an automated email letting you know that sources > have recently been pushed out. You can download these newer > sources directly from > http://ironpython.codeplex.com/SourceControl/changeset/view/76456. > > MODIFIED SOURCES > $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Chiron.csproj > $/IronPython/IronPython_Main/Msi/IronStudio/IronStudio.msm.wproj > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.heller at gmail.com Wed Aug 25 18:19:31 2010 From: brad.heller at gmail.com (Brad Heller) Date: Wed, 25 Aug 2010 09:19:31 -0700 Subject: [IronPython] IronPython Security Model Message-ID: I'd like to embed IronPython in my application, however I'd like to be able to prevent the user from doing certain things. For instance, I'd like to make sure they can't open a socket, or access the file system or network resources. Is this currently possible? I haven't been able to find any information on the IronPython security model besides some post somewhere saying "you have complete control over the IronPython security model!" Anyone have any ideas? Thanks, Brad Heller -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Aug 25 18:28:58 2010 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 25 Aug 2010 16:28:58 +0000 Subject: [IronPython] IronPython Security Model In-Reply-To: References: Message-ID: You'll need to use the CLR security model - IronPython its self doesn't have a security model and we rely upon the CLR team to make sure they get their security model right. The easiest thing to do is to create a sandboxed app domain (http://msdn.microsoft.com/en-us/library/bb763046.aspx) and then call Python.CreateEngine(appDomain) to create the ScriptEngine in the remote domain. Note you shouldn't have IronPython or the DLR assemblies in the full trust list. From there you can give the remote domain a MarshalByRefObject which it can use to call back into your object model or enable things which you want to filter. You can also put your own assemblies in the full trust list and make sure you do the appropriate validation for any calls. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brad Heller Sent: Wednesday, August 25, 2010 9:20 AM To: users at lists.ironpython.com Subject: [IronPython] IronPython Security Model I'd like to embed IronPython in my application, however I'd like to be able to prevent the user from doing certain things. For instance, I'd like to make sure they can't open a socket, or access the file system or network resources. Is this currently possible? I haven't been able to find any information on the IronPython security model besides some post somewhere saying "you have complete control over the IronPython security model!" Anyone have any ideas? Thanks, Brad Heller -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at kurtrichardson.com Thu Aug 26 01:02:51 2010 From: kurt at kurtrichardson.com (Kurt A. Richardson) Date: Wed, 25 Aug 2010 16:02:51 -0700 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage Message-ID: <4C75A11B.50009@kurtrichardson.com> Hi All I wonder if anyone has tried to access the serial port from a web app using Iron Python. I have a simple default webpage which is using IronPython as the code behind. My 'FanOn' function calls a little IronPython script that opens up the serial port and sends an ZigBee communications packet to a little home made device which would then turn a fan on. I have found a web page that describes how to access the Serial port on the server using C#: http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/a5ff20cf-0bb5-4a3e-aed4-24c6290f66cd/ But I don't know how to translate this into IronPython. In my FanOn function I have: sx = SecurityPermission(SecurityPermissionFlag.UnmanagedCode) sx.Assert() after importing System.Security.Permissions However I don't know how to decorate the function itself with: [SuppressUnmanagedCodeSecurityAttribute()] Any ideas would be greatly appreciated. Kind regards, Kurt PS A simplified version of my FanOn script which is containined in a Default.aspx.py file behind Default.aspx: def FanOn(sender, e): sx = SecurityPermission(SecurityPermissionFlag.UnmanagedCode) sx.Assert() sp = serial_ports.port('COM4') sp.open() sp.write_packet('7E001017060013A20040645580FFFE024431053B') sp.close() lblResponse.Text = "Fan successfully turned on" From vernondcole at gmail.com Thu Aug 26 01:44:17 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 25 Aug 2010 17:44:17 -0600 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage In-Reply-To: <4C75A11B.50009@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> Message-ID: Kurt: Have you tried http://pyserial.sourceforge.net/ ? It is documented to run on IronPython, either dotNet or MONO. I have a setup similar to what you describe, but using x.10 hardware which is controlled using a module called x10.py, which in turn calls serial.py. It controls the air conditioner in my home office/computer room and the heaters in two iguana cages. I use OneWire devices to sense the temperature and a Python program completes the feedback loop. The iguana cages are heated by incandescent heat lamps which are connected to x.10 dimmers. The Python program can hold them to within 0.5 degrees (F) and sets back the temperature and turns the lights off at night. Fun project! I hope you have similar success with your ZigBee device. -- Vernon On Wed, Aug 25, 2010 at 5:02 PM, Kurt A. Richardson wrote: > Hi All > > I wonder if anyone has tried to access the serial port from a web app using > Iron Python. I have a simple default webpage which is using IronPython as > the code behind. My 'FanOn' function calls a little IronPython script that > opens up the serial port and sends an ZigBee communications packet to a > little home made device which would then turn a fan on. > > I have found a web page that describes how to access the Serial port on the > server using C#: > > > http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/a5ff20cf-0bb5-4a3e-aed4-24c6290f66cd/ > > But I don't know how to translate this into IronPython. In my FanOn > function I have: > > sx = SecurityPermission(SecurityPermissionFlag.UnmanagedCode) > sx.Assert() > > after importing System.Security.Permissions > > However I don't know how to decorate the function itself with: > > [SuppressUnmanagedCodeSecurityAttribute()] > > Any ideas would be greatly appreciated. > > Kind regards, > > Kurt > > PS A simplified version of my FanOn script which is containined in a > Default.aspx.py file behind Default.aspx: > > def FanOn(sender, e): > sx = SecurityPermission(SecurityPermissionFlag.UnmanagedCode) > sx.Assert() > sp = serial_ports.port('COM4') > sp.open() > sp.write_packet('7E001017060013A20040645580FFFE024431053B') > sp.close() > lblResponse.Text = "Fan successfully turned on" > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at kurtrichardson.com Thu Aug 26 01:53:47 2010 From: kurt at kurtrichardson.com (Kurt A. Richardson) Date: Wed, 25 Aug 2010 16:53:47 -0700 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage In-Reply-To: <4C75A11B.50009@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> Message-ID: <4C75AD0B.6070007@kurtrichardson.com> Thanks Vernon I did look at Pyserial, but then I realized that with IronPython I could just use System.IO.Ports.SerialPort to do it all anyway... then it seemed pointless to use PySerial if the capability is already available in IronPython. It works fine on Mono too, and I have run successful tests in Linux Juanty (which my PlugPC runs). The problem I have now is not talking to the serial port per se... it is doing it from within a web browser, which as I understand it is a security issue. The browser security policy just won't give me access to the serial port whatever library I might be using. The link I posted earlier shows how to overcome the security restrictions in C# - I just don't know how to translate this into an IronPython class :-( Bye for now, Kurt From kurt at kurtrichardson.com Thu Aug 26 01:56:34 2010 From: kurt at kurtrichardson.com (Kurt A. Richardson) Date: Wed, 25 Aug 2010 16:56:34 -0700 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage In-Reply-To: <4C75AD0B.6070007@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> <4C75AD0B.6070007@kurtrichardson.com> Message-ID: <4C75ADB2.8040502@kurtrichardson.com> On 8/25/2010 4:53 PM, Kurt A. Richardson wrote: > Thanks Vernon > > I did look at Pyserial, but then I realized that with IronPython I > could just use System.IO.Ports.SerialPort to do it all anyway... then > it seemed pointless to use PySerial if the capability is already > available in IronPython. It works fine on Mono too, and I have run > successful tests in Linux Juanty (which my PlugPC runs). The problem > I have now is not talking to the serial port per se... it is doing it > from within a web browser, which as I understand it is a security > issue. The browser security policy just won't give me access to the > serial port whatever library I might be using. The link I posted > earlier shows how to overcome the security restrictions in C# - I just > don't know how to translate this into an IronPython class :-( > > Bye for now, Kurt BTW Your project sounds pretty cool - not wishing to clutter this thread, but how reliable are you finding the X10. I have a TED5000 which just monitors my total load, and it sux - this is why I chose wireless ZigBees when putting together my Smart Home Network. Ta ta for now, Kurt From dinov at microsoft.com Thu Aug 26 02:40:27 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 26 Aug 2010 00:40:27 +0000 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage In-Reply-To: <4C75A11B.50009@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> Message-ID: Kurt wrote: > > Hi All > > I wonder if anyone has tried to access the serial port from a web app > using Iron Python. I have a simple default webpage which is using > IronPython as the code behind. My 'FanOn' function calls a little > IronPython script that opens up the serial port and sends an ZigBee > communications packet to a little home made device which would then > turn > a fan on. > > I have found a web page that describes how to access the Serial port on > the server using C#: > > http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/a5ff20cf- > 0bb5-4a3e-aed4-24c6290f66cd/ > > But I don't know how to translate this into IronPython. In my FanOn > function I have: > > sx = SecurityPermission(SecurityPermissionFlag.UnmanagedCode) > sx.Assert() > > after importing System.Security.Permissions > > However I don't know how to decorate the function itself with: > > [SuppressUnmanagedCodeSecurityAttribute()] > > Any ideas would be greatly appreciated. > Do you need all of the security goo? My guess would be that all of this isn't necessary. It should only be necessary if you're running in a partial trust scenario where your assembly is capable of asserting permissions. That could be the case if you're in ASP.NET's medium trust. Otherwise it should make no difference. If you do need this you may be unable to do this w/ IronPython. The assert is associated with a stack frame and we'll actually perform the call to assert inside of another method, unwind the stack, and then it'll be gone. My best guess is you'd need to have a C# wrapper for this to work from partial trust in ASP.NET. From vernondcole at gmail.com Thu Aug 26 03:29:53 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 25 Aug 2010 19:29:53 -0600 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage In-Reply-To: <4C75ADB2.8040502@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> <4C75AD0B.6070007@kurtrichardson.com> <4C75ADB2.8040502@kurtrichardson.com> Message-ID: What x.10 misses in reliability, it makes up for by being inexpensive. I have had the x.10 devices miss a command, sometimes, probably less than 1%. It's not a problem with brighten or dim commands, the temperature feedback will just repeat the command next loop if neeed. To turn things on or off, the following code completely cures the problem. ;-) def x10out(controlString): """Send "controlSring" to x.10 home automation transmitter.""" controlString = controlString.upper() print('x10out=',controlString) x10.sendCommands(x10device,controlString) lastToken = controlString.rsplit(' ',1)[1] if lastToken in ['ON','OFF']: #auto retry for "on" or "off" time.sleep(0.2) # just in case the first one did not work x10.sendCommands(x10device,controlString) time.sleep(0.2) x10.sendCommands(x10device,controlString) I missed your comment about a web BROWSER. Somehow, I read it as a web SERVER. Yes, direct control of serial ports would be a serious security risk from a browser, and probably SHOULD be hard or impossible to do. I think it might be much easier to roll a custom program using Sockets for your home controller. IMHO, people tend to use browser-based technology a lot because it's the first idea that comes to mind. The first idea may not be the best. Using Python sockets may be simpler and is SURE to have a smaller footprint. -- Vernon On Wed, Aug 25, 2010 at 5:56 PM, Kurt A. Richardson wrote: > On 8/25/2010 4:53 PM, Kurt A. Richardson wrote: > >> Thanks Vernon >> >> I did look at Pyserial, but then I realized that with IronPython I could >> just use System.IO.Ports.SerialPort to do it all anyway... then it seemed >> pointless to use PySerial if the capability is already available in >> IronPython. It works fine on Mono too, and I have run successful tests in >> Linux Juanty (which my PlugPC runs). The problem I have now is not talking >> to the serial port per se... it is doing it from within a web browser, which >> as I understand it is a security issue. The browser security policy just >> won't give me access to the serial port whatever library I might be using. >> The link I posted earlier shows how to overcome the security restrictions >> in C# - I just don't know how to translate this into an IronPython class :-( >> >> Bye for now, Kurt >> > BTW Your project sounds pretty cool - not wishing to clutter this thread, > but how reliable are you finding the X10. I have a TED5000 which just > monitors my total load, and it sux - this is why I chose wireless ZigBees > when putting together my Smart Home Network. > > Ta ta for now, Kurt > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Thu Aug 26 17:50:29 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Thu, 26 Aug 2010 08:50:29 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <46a3fb64-72a3-4fa6-be4b-a9a047773a35@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/76515. ADDED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ExtensionMethodSet.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonExtensionBinder.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/ExtensionMethodTest.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/ErrorMetaObject.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Languages/IronPython/IronPython/IronPython.csproj $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ClrModule.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ExtensionMethodSet.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/ModuleContext.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/MetaUserObject.Members.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonBinder.Create.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonBinder.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonExtensionBinder.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonGetMemberBinder.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Binding/PythonOverloadResolver.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Runtime/Types/PythonType.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/ExtensionMethodTest.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPythonTest/IronPythonTest.csproj $/IronPython/IronPython_Main/Languages/IronPython/Tests/test_cliclass.py $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/ConditionalBuilder.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.DeleteMember.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.GetMember.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.SetMember.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/ErrorMetaObject.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Actions/Calls/TypeInferer.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Utils/CollectionUtils.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Utils/HashSet.cs From ecullen at fibertel.com.ar Thu Aug 26 22:20:04 2010 From: ecullen at fibertel.com.ar (ecullen) Date: Thu, 26 Aug 2010 17:20:04 -0300 Subject: [IronPython] how to access a SysModule variable from a script Message-ID: hi all I have a program in c# which hosts IronPython scripts. I set a variable in SysModule using this: Dictionary options = new Dictionary(); options.Add("ShowClrExceptions", true); options.Add("ExceptionDetail", true); options.Add("Debug", true); ScriptEngine _scriptEngine = Python.CreateEngine(options); ScriptScope _scriptScope = _scriptEngine.CreateScope(); ScriptScope sysScope = scriptEngine.GetSysModule(); sysScope.SetVariable("mySysVar", true); _scriptEngine.ExecuteFile("something.py", _scriptScope); Now, I want to read variable "mySysVar" from inside the script "something.py". How can I do that? I tried ------------ import sys if sys.mySysVar: ... ------------- and also ------------- sys["mySysVar"] ------------- but they don't work. Thanks in advance Ernesto Cullen -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Aug 26 22:30:32 2010 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 26 Aug 2010 20:30:32 +0000 Subject: [IronPython] how to access a SysModule variable from a script In-Reply-To: References: Message-ID: Do you perhaps have 2 different script engines here? It appears you are creating "_scriptEngine" and executing the code against that engine. But you are getting the sys module from "scriptEngine" and setting the variable against the script engine. If I change these to both use the same script engine it works and I can access the variable using "sys.mySysVar". From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of ecullen Sent: Thursday, August 26, 2010 1:20 PM To: users Subject: [IronPython] how to access a SysModule variable from a script hi all I have a program in c# which hosts IronPython scripts. I set a variable in SysModule using this: Dictionary options = new Dictionary(); options.Add("ShowClrExceptions", true); options.Add("ExceptionDetail", true); options.Add("Debug", true); ScriptEngine _scriptEngine = Python.CreateEngine(options); ScriptScope _scriptScope = _scriptEngine.CreateScope(); ScriptScope sysScope = scriptEngine.GetSysModule(); sysScope.SetVariable("mySysVar", true); _scriptEngine.ExecuteFile("something.py", _scriptScope); Now, I want to read variable "mySysVar" from inside the script "something.py". How can I do that? I tried ------------ import sys if sys.mySysVar: ... ------------- and also ------------- sys["mySysVar"] ------------- but they don't work. Thanks in advance Ernesto Cullen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at kurtrichardson.com Thu Aug 26 23:19:24 2010 From: kurt at kurtrichardson.com (Kurt A. Richardson) Date: Thu, 26 Aug 2010 14:19:24 -0700 Subject: [IronPython] Accessing Serial Port from IronPython driven Webpage In-Reply-To: <4C75ADB2.8040502@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> <4C75AD0B.6070007@kurtrichardson.com> <4C75ADB2.8040502@kurtrichardson.com> Message-ID: <4C76DA5C.1000100@kurtrichardson.com> On 8/25/2010 4:56 PM, Kurt A. Richardson wrote: > On 8/25/2010 4:53 PM, Kurt A. Richardson wrote: >> Thanks Vernon >> >> I did look at Pyserial, but then I realized that with IronPython I >> could just use System.IO.Ports.SerialPort to do it all anyway... then >> it seemed pointless to use PySerial if the capability is already >> available in IronPython. It works fine on Mono too, and I have run >> successful tests in Linux Juanty (which my PlugPC runs). The problem >> I have now is not talking to the serial port per se... it is doing it >> from within a web browser, which as I understand it is a security >> issue. The browser security policy just won't give me access to the >> serial port whatever library I might be using. The link I posted >> earlier shows how to overcome the security restrictions in C# - I >> just don't know how to translate this into an IronPython class :-( >> >> Bye for now, Kurt > BTW Your project sounds pretty cool - not wishing to clutter this > thread, but how reliable are you finding the X10. I have a TED5000 > which just monitors my total load, and it sux - this is why I chose > wireless ZigBees when putting together my Smart Home Network. > > Ta ta for now, Kurt Well I'm a complete berk - I was attempting to access the server's serial port via a browser on the same server - so no real security issue at all... but having another window open with an open serial connection is certainly a problem!??!!??! Explains why I kept getting Access Denied - some of these error messages really could be more helpful :-) As soon as I closed the other connection, I could connect from my browser fine and successfully turned a fan off in my office from my iPhone today with no trouble. Thanks for the tips... Bye for now, Kurt From kurt at kurtrichardson.com Fri Aug 27 00:21:15 2010 From: kurt at kurtrichardson.com (Kurt A. Richardson) Date: Thu, 26 Aug 2010 15:21:15 -0700 Subject: [IronPython] IronPython-based web service and entity framework In-Reply-To: <4C76DA5C.1000100@kurtrichardson.com> References: <4C75A11B.50009@kurtrichardson.com> <4C75AD0B.6070007@kurtrichardson.com> <4C75ADB2.8040502@kurtrichardson.com> <4C76DA5C.1000100@kurtrichardson.com> Message-ID: <4C76E8DB.1000104@kurtrichardson.com> Hi List I wonder if anyone can point me towards an example of building a webservice using IronPython. I found a couple of posts regarding dynamic web service helpers but they seemed somewhat date now that we have .NET 4.0 and IPY 2.7. As a bit of a follow up, does 2.7 support the latest version of the Entity Framework? I haven't used this before as it seems similar to LINQ to SQL in someways so thought I'd give it a shot. Many thanks in advance. Kurt From Larry.Jones at aspentech.com Mon Aug 30 15:38:32 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 09:38:32 -0400 Subject: [IronPython] Unittest Module Unavailable in V2.7a1 Message-ID: My team is currently using VS2010 for work. I want to demonstrate that using IronPython as our "unit testing language" can be more productive than using either NUnit or Microsoft Test. In order to integrate with VS2010, I believe I must use IronPython 2.7a1. I believe this is the only release that includes the IronPython Tools. However, IronPython 2.7a1 fails when executing 'import unittest'. I've submitted a work item, 28709, to the IronPython issue tracker; however, I'm wondering if another work around exists then writing code in 2.6.1 - which will execute outside VS2010 - but cannot be executed from within Visual Studio (it invoke IronPython 2.7a1). Thanks. Have a great day! 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Aug 30 16:32:50 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 30 Aug 2010 17:32:50 +0300 Subject: [IronPython] Unittest Module Unavailable in V2.7a1 In-Reply-To: References: Message-ID: <4C7BC112.8040909@voidspace.org.uk> On 30/08/2010 16:38, Jones, Larry wrote: > > My team is currently using VS2010 for work. I want to demonstrate that > using IronPython as our "unit testing language" can be more productive > than using either NUnit or Microsoft Test. > > In order to integrate with VS2010, I believe I must use IronPython > 2.7a1. I believe this is the only release that includes the IronPython > Tools. However, IronPython 2.7a1 fails when executing 'import > unittest'. I've submitted a work item, 28709, to the IronPython issue > tracker; however, I'm wondering if another work around exists then > writing code in 2.6.1 -- which will execute outside VS2010 -- but > cannot be executed from within Visual Studio (it invoke IronPython 2.7a1). > The IronPython team is aware of this problem, it was caused by a 'bug' in the tools that package the installer. A simple workaround (that will probably work) is to copy the unittest package from a CPython 2.7 installation into your IronPython Lib directory. In IronPython 2.7 the unittest package is missing some files. All the best, Michael Foord > Thanks. > > Have a great day! > > > ****************************************************************** > 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 at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Jones at aspentech.com Mon Aug 30 17:32:06 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 11:32:06 -0400 Subject: [IronPython] Unittest Module Unavailable in V2.7a1 In-Reply-To: <4C7BC112.8040909@voidspace.org.uk> References: <4C7BC112.8040909@voidspace.org.uk> Message-ID: Thanks, Michael, for the information. I copied the file unittest.py from my IronPython 2.6 installation to my IronPython 2.7 installation. It did seem to work, although discovering that in 2.7 unittest is a directory containing a number of other files, was a bit disconcerting. I renamed the v2.7 unittest directory (to unittest.000) and then copied unittest.py from the IronPython 2.6 installation. I greatly appreciate your help on this. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, August 30, 2010 9:33 AM To: Discussion of IronPython Subject: Re: [IronPython] Unittest Module Unavailable in V2.7a1 On 30/08/2010 16:38, Jones, Larry wrote: My team is currently using VS2010 for work. I want to demonstrate that using IronPython as our "unit testing language" can be more productive than using either NUnit or Microsoft Test. In order to integrate with VS2010, I believe I must use IronPython 2.7a1. I believe this is the only release that includes the IronPython Tools. However, IronPython 2.7a1 fails when executing 'import unittest'. I've submitted a work item, 28709, to the IronPython issue tracker; however, I'm wondering if another work around exists then writing code in 2.6.1 - which will execute outside VS2010 - but cannot be executed from within Visual Studio (it invoke IronPython 2.7a1). The IronPython team is aware of this problem, it was caused by a 'bug' in the tools that package the installer. A simple workaround (that will probably work) is to copy the unittest package from a CPython 2.7 installation into your IronPython Lib directory. In IronPython 2.7 the unittest package is missing some files. All the best, Michael Foord Thanks. Have a great day! ****************************************************************** 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 at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Aug 30 17:35:40 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 30 Aug 2010 18:35:40 +0300 Subject: [IronPython] Unittest Module Unavailable in V2.7a1 In-Reply-To: References: <4C7BC112.8040909@voidspace.org.uk> Message-ID: <4C7BCFCC.3070607@voidspace.org.uk> On 30/08/2010 18:32, Jones, Larry wrote: > > Thanks, Michael, for the information. I copied the file unittest.py > from my IronPython 2.6 installation to my IronPython 2.7 installation. > > It did seem to work, although discovering that in 2.7 unittest is a > directory containing a number of other files, was a bit disconcerting. > I renamed the v2.7 unittest directory (to unittest.000) and then > copied unittest.py from the IronPython 2.6 installation. > > I greatly appreciate your help on this. > In Python 2.6 unittest was a single file (unittest.py). In Python 2.7 it is a package (a directory containing several modules). The unittest package in Python 2.7 is a lot more capable, but using the Python 2.6 version of unittest.py will certainly work. All the best, Michael Foord > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Michael Foord > *Sent:* Monday, August 30, 2010 9:33 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Unittest Module Unavailable in V2.7a1 > > On 30/08/2010 16:38, Jones, Larry wrote: > > My team is currently using VS2010 for work. I want to demonstrate that > using IronPython as our "unit testing language" can be more productive > than using either NUnit or Microsoft Test. > > In order to integrate with VS2010, I believe I must use IronPython > 2.7a1. I believe this is the only release that includes the IronPython > Tools. However, IronPython 2.7a1 fails when executing 'import > unittest'. I've submitted a work item, 28709, to the IronPython issue > tracker; however, I'm wondering if another work around exists then > writing code in 2.6.1 -- which will execute outside VS2010 -- but > cannot be executed from within Visual Studio (it invoke IronPython 2.7a1). > > > The IronPython team is aware of this problem, it was caused by a 'bug' > in the tools that package the installer. > > A simple workaround (that will probably work) is to copy the unittest > package from a CPython 2.7 installation into your IronPython Lib > directory. In IronPython 2.7 the unittest package is missing some files. > > All the best, > > Michael Foord > > > > > Thanks. > > Have a great day! > > > ****************************************************************** > 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 at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Jones at aspentech.com Mon Aug 30 23:13:16 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 17:13:16 -0400 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging Message-ID: I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Aug 30 23:17:38 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 30 Aug 2010 21:17:38 +0000 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: References: Message-ID: import System System.Diagnostics.Debugger.IsAttached Will determine if the debugger is attached or not. Personally I hate code which checks this though but your usage sounds safe enough :) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jones, Larry Sent: Monday, August 30, 2010 2:13 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Prevention of SystemExit Dialog While Debugging I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! ****************************************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Aug 30 23:17:38 2010 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 30 Aug 2010 21:17:38 +0000 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: References: Message-ID: import System System.Diagnostics.Debugger.IsAttached Will determine if the debugger is attached or not. Personally I hate code which checks this though but your usage sounds safe enough :) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jones, Larry Sent: Monday, August 30, 2010 2:13 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Prevention of SystemExit Dialog While Debugging I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! ****************************************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Aug 30 23:24:42 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 31 Aug 2010 00:24:42 +0300 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: References: Message-ID: <4C7C219A.2030704@voidspace.org.uk> On 31/08/2010 00:13, Jones, Larry wrote: > > I'm writing unit tests in IronPython. > > The implementation of unittest.main() calls sys.exit() when finished > even if no testing errors occurred. Consequently, the Visual Studio > debugger presents a dialog indicating that the SystemExit exception > was unhandled. Running from the console, I do not see any evidence of > the SystemExit exception. Because my colleagues are not familiar with > IronPython, seeing this error in the debugger will cause them to think > that some problem occurred on exit. > Is your code calling unittest.main() or is Visual Studio calling it for you? In the version of unittest that comes with Python 2.7 you can call unittest.main(exit=False). Alternatively you can just catch and ignore this exception yourself. All the best, Michael > Although I suspect I can configure Visual Studio to ignore this > exception, I'd prefer not to because it may indicate an actual problem. > > How can I determine if an IronPython script is running under the VS > debugger? > > Thanks. > > Have a great day! > > > ****************************************************************** > 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 at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Aug 30 23:24:42 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 31 Aug 2010 00:24:42 +0300 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: References: Message-ID: <4C7C219A.2030704@voidspace.org.uk> On 31/08/2010 00:13, Jones, Larry wrote: > > I'm writing unit tests in IronPython. > > The implementation of unittest.main() calls sys.exit() when finished > even if no testing errors occurred. Consequently, the Visual Studio > debugger presents a dialog indicating that the SystemExit exception > was unhandled. Running from the console, I do not see any evidence of > the SystemExit exception. Because my colleagues are not familiar with > IronPython, seeing this error in the debugger will cause them to think > that some problem occurred on exit. > Is your code calling unittest.main() or is Visual Studio calling it for you? In the version of unittest that comes with Python 2.7 you can call unittest.main(exit=False). Alternatively you can just catch and ignore this exception yourself. All the best, Michael > Although I suspect I can configure Visual Studio to ignore this > exception, I'd prefer not to because it may indicate an actual problem. > > How can I determine if an IronPython script is running under the VS > debugger? > > Thanks. > > Have a great day! > > > ****************************************************************** > 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 at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Jones at aspentech.com Tue Aug 31 01:40:16 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 19:40:16 -0400 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: <4C7C219A.2030704@voidspace.org.uk> References: <4C7C219A.2030704@voidspace.org.uk> Message-ID: Michael, Thanks for the information. My code calls unittest.main(). I could not locate the 2.7 version of unittest.main that accepted the exit=False parameter. I suspect it is in the CodePlex source code tree and not in the downloaded V7.2a1. I will probably utilize the solution suggested by Dino and trap the error if my process is attached to a debugger. It may not the best solution, but adequate for my prototype. Have a great day! From: Michael Foord [mailto:fuzzyman at voidspace.org.uk] Sent: Monday, August 30, 2010 4:25 PM To: Discussion of IronPython Cc: Jones, Larry; users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] Prevention of SystemExit Dialog While Debugging On 31/08/2010 00:13, Jones, Larry wrote: I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Is your code calling unittest.main() or is Visual Studio calling it for you? In the version of unittest that comes with Python 2.7 you can call unittest.main(exit=False). Alternatively you can just catch and ignore this exception yourself. All the best, Michael Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! ****************************************************************** 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 at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Jones at aspentech.com Tue Aug 31 01:40:16 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 19:40:16 -0400 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: <4C7C219A.2030704@voidspace.org.uk> References: <4C7C219A.2030704@voidspace.org.uk> Message-ID: Michael, Thanks for the information. My code calls unittest.main(). I could not locate the 2.7 version of unittest.main that accepted the exit=False parameter. I suspect it is in the CodePlex source code tree and not in the downloaded V7.2a1. I will probably utilize the solution suggested by Dino and trap the error if my process is attached to a debugger. It may not the best solution, but adequate for my prototype. Have a great day! From: Michael Foord [mailto:fuzzyman at voidspace.org.uk] Sent: Monday, August 30, 2010 4:25 PM To: Discussion of IronPython Cc: Jones, Larry; users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] Prevention of SystemExit Dialog While Debugging On 31/08/2010 00:13, Jones, Larry wrote: I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Is your code calling unittest.main() or is Visual Studio calling it for you? In the version of unittest that comes with Python 2.7 you can call unittest.main(exit=False). Alternatively you can just catch and ignore this exception yourself. All the best, Michael Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! ****************************************************************** 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 at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Jones at aspentech.com Tue Aug 31 01:43:40 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 19:43:40 -0400 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: References: Message-ID: Dino, Thanks for the note. I agree that I do not want to check this usage, but since it is a prototype designed to help persuade others on the productivity of unit tests in IronPython, I think it is adequate. Have a great day! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, August 30, 2010 4:18 PM To: Discussion of IronPython; users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] Prevention of SystemExit Dialog While Debugging import System System.Diagnostics.Debugger.IsAttached Will determine if the debugger is attached or not. Personally I hate code which checks this though but your usage sounds safe enough J From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jones, Larry Sent: Monday, August 30, 2010 2:13 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Prevention of SystemExit Dialog While Debugging I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! ****************************************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Jones at aspentech.com Tue Aug 31 01:43:40 2010 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Mon, 30 Aug 2010 19:43:40 -0400 Subject: [IronPython] Prevention of SystemExit Dialog While Debugging In-Reply-To: References: Message-ID: Dino, Thanks for the note. I agree that I do not want to check this usage, but since it is a prototype designed to help persuade others on the productivity of unit tests in IronPython, I think it is adequate. Have a great day! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, August 30, 2010 4:18 PM To: Discussion of IronPython; users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] Prevention of SystemExit Dialog While Debugging import System System.Diagnostics.Debugger.IsAttached Will determine if the debugger is attached or not. Personally I hate code which checks this though but your usage sounds safe enough J From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jones, Larry Sent: Monday, August 30, 2010 2:13 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Prevention of SystemExit Dialog While Debugging I'm writing unit tests in IronPython. The implementation of unittest.main() calls sys.exit() when finished even if no testing errors occurred. Consequently, the Visual Studio debugger presents a dialog indicating that the SystemExit exception was unhandled. Running from the console, I do not see any evidence of the SystemExit exception. Because my colleagues are not familiar with IronPython, seeing this error in the debugger will cause them to think that some problem occurred on exit. Although I suspect I can configure Visual Studio to ignore this exception, I'd prefer not to because it may indicate an actual problem. How can I determine if an IronPython script is running under the VS debugger? Thanks. Have a great day! ****************************************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Tue Aug 31 18:04:25 2010 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 31 Aug 2010 09:04:25 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/76698. ADDED SOURCES $/IronPython/IronPython_Main/Msi/Python/Msi/Silverlight.wxi DELETED SOURCES $/IronPython/IronPython_Main/Msi/Python/Msi/Core.wxs MODIFIED SOURCES $/IronPython/IronPython_Main/Readme.html $/IronPython/IronPython_Main/External.LCA_RESTRICTED/Languages/IronRuby/yaml/IronRuby.Libraries.Yaml/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Hosts/MerlinWeb/Microsoft.Scripting.AspNet/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Hosts/Silverlight/Chiron/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/AssemblyVersion.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Hosting/Python.cs $/IronPython/IronPython_Main/Languages/IronPython/IronPython/Hosting/PythonCommandLine.cs $/IronPython/IronPython_Main/Languages/IronPython/Samples/BadPaint/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/Samples/DynamicWebServiceHelpers/sources/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/Samples/tests/Direct3D/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/Samples/tests/FMsynth/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/Samples/tests/Puzzle/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/IronPython/Samples/tests/UIRunner/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/Ruby/ClassInitGenerator/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/Ruby/Console/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/Ruby/IronRuby.Tests/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/Ruby/Libraries.LCA_RESTRICTED/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/Ruby/Ruby/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Languages/Ruby/Tests/Tools/ParseOnly/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Msi/IronStudio/IronStudio.msm.wproj $/IronPython/IronPython_Main/Msi/IronStudio/IronStudio.wxs $/IronPython/IronPython_Main/Msi/Python/Msi/IronPython.Msi.wproj $/IronPython/IronPython_Main/Msi/Python/Msi/IronPython.wxs $/IronPython/IronPython_Main/Msi/Python/Msi/Silverlight.wxi $/IronPython/IronPython_Main/Msi/Python/Msm/IpyRedist.wxs $/IronPython/IronPython_Main/Msi/Python/Msm/IronPython.Msm.wproj $/IronPython/IronPython_Main/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting.Metadata/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/ExpressionTree/ETSample1_CS/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/ExpressionTree/UESamples/ConsoleApplication1/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/Hosting/ShapeScript/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/LibraryAuthors/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/Silverlight/Hosting/Python/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/Silverlight/Hosting/Ruby/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/sympl/csharp-cponly/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/sympl/csharp-cponly/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Samples/sympl/csharp/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/AstTest/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/ComTest/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/DLRTestHost/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/ETScenarios/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/ETScenariosCSLinq/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/HostingTest/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/HostingTestRunner/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/Metadata/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/NoPia/NoPiaHelper2/NoPiaHelper2/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/NoPia/NoPiaHelperClass/NoPiaHelperClass/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/NoPia/Tests/Tests/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/Perf/PerfV2Nodes/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/PerfHost/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/PerfV1Nodes/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/RowanTest.Common/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/SecurityTests/DynamicTest/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/SecurityTests/SecurityTests/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/SiteTest/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/TestAst/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/TestHost/Microsoft.Silverlight.TestHostCritical/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/TestHost/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Runtime/Tests/TestInternalDLR/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/AnalysisTest/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonTools/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/IronPythonToolsCore/PythonRuntimeHost.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronPythonToolsCore/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudio/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/IronStudioCore/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/RemoteScriptFactory/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Tools/IronStudio/UnitTests/Properties/AssemblyInfo.cs CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1990102 Date: 8/26/2010 1:17:29 PM Add required Silverlight 3 and 4 runtime and SDK binaries so Silverlight builds can occur without having those Silverlight versions installed. - Adds a SilverlightSdkPath MSBuild variable to Common.proj - Updates package_slvx.bat to work in a Git repo - Adds Clean.bat for cleaning all binaries - Updates Alias.txt for Silverlight builds Author: "Jimmy Schementi" Date: 8/2/2010 12:37:19 AM (Shelveset: JimmysSilverlightBuild;REDMOND\tomat | SNAP CheckinId: m12228) -------------------------------------------------------------------------------- Changeset Id: 1990102 Date: 8/26/2010 1:17:29 PM Add required Silverlight 3 and 4 runtime and SDK binaries so Silverlight builds can occur without having those Silverlight versions installed. - Adds a SilverlightSdkPath MSBuild variable to Common.proj - Updates package_slvx.bat to work in a Git repo - Adds Clean.bat for cleaning all binaries - Updates Alias.txt for Silverlight builds Author: "Jimmy Schementi" Date: 8/2/2010 12:37:19 AM (Shelveset: JimmysSilverlightBuild;REDMOND\tomat | SNAP CheckinId: m12228)