Re: [IronPython] Congratulations to Michael Foord on Receiving the Community Service Award
I think you're the only author I've seen (except for those who have a team of researchers behind them, as some of the big names do) who didn't respond with fright and alarm to the suggestion of writing another book. Remarkable. Go for it. gdr I'm thinking a dynamic data framework, so dynamic language folks can have a choice other than the static ORM's (EF, NH, etc.). And congratulations on your award (richly deserved) and your book (deservedly praised). Hank On Fri, Nov 5, 2010 at 12:47 PM, Michael Foord mich...@voidspace.org.ukwrote: On 04/11/2010 12:51, Pablo Dalmazzo wrote: Congratulations! Write another book! :) Thanks all. :-) I'll add writing another book to my list of things to do... Michael -- From: jcao...@gmail.com Date: Wed, 3 Nov 2010 23:32:34 -0500 To: users@lists.ironpython.com Subject: [IronPython] Congratulations to Michael Foord on Receiving the Community Service Award The Python Software Foundation has presented the Community Service Award for the third quarter of 2010 to Michael Foordhttp://www.voidspace.org.uk/python/weblog/index.shtml in recognition of his incredible work in promoting Python everywhere he could. Michael is active on IRC channels, mailing lists, conferences, sprints and similar events. On the development side, he has been doing incredible work on unitest and unitest2. Michael also helps maintain the Planet Python RSS feed and python.org website, and with organizing the Europython meeting and Summit http://www.europython.eu/. The Python Software Foundation is pleased to recognize Michael's contributions to the community. http://pyfound.blogspot.com/2010/11/third-quarter-community-service-awards.html Well deserved! Thanks for all the hard work, Michael. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.voidspace.org.uk/ 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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython / 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? s 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 ji...@schementi.comwrote: 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 eyvind.axel...@profdoc.no wrote: So, no response from the IPY team on this issue? Eyvind. *Fra:* users-boun...@lists.ironpython.com [mailto: users-boun...@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 h...@prosysplus.com 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 tony.me...@gmail.com wrote: On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy jdha...@gmail.com 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
Re: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query?
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 vernondc...@gmail.com 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 cenov...@bakalari.czwrote: 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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython / DLR Direction
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 tony.me...@gmail.com wrote: On Sun, Aug 8, 2010 at 6:19 AM, Jeff Hardy jdha...@gmail.com 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
Re: [IronPython] .Net attributes/decorators
Thanks for the explanation. I like the opt in idea -- taken to its fullest, that could allow .Net-style decorators on an opt-in module basis, could it not? And I see the point about the many platforms in one codebase approach you describe as a way of enabling the larger Python community. By pursuing both approaches, the many-in-one and the opt-in to the fullest, I think IPy can continue to fulfill what I understand now to have been the original goal, of serving the Python community, while also providing an enticing alternative to static .Net languages for non-Pythonistas looking for a more comfortable home. In the meantime, I know where to go when I get stuck on how to use ClrType.py to use .Net attributes. You probably know where I can go, too, but we're probably thinking of different places. s thanks again, Hank On Tue, May 18, 2010 at 4:50 PM, Dino Viehland di...@microsoft.com wrote: The answer is kind of both. When it comes to the core language grammar we are (and I believe will always be) an equivalent set. That’s rather important in that any code which is .NET specific can still be parsed by other Python implementations and therefore you can do various if I’m running on IronPython do this else if I’m on Jython do that or if I’m on CPython do something else – which is a fairly common pattern and even shows up in the standard library. When it comes to the various builtin types we intend to be a superset but that superset is only available after the user has specifically opted in to IronPython. So let’s look at some examples how this has played out. To add generic support we used Python’s existing indexing support rather than adding parsing support for something like Dictionaryint, int which would have matched C#. But at the same time we don’t want to modify the core objects too much – for example a future version of CPython could choose to add indexing support to built-in functions to add some new feature of their own. Therefore our built-in functions which are generic are actually a subtype of the normal built-in function type and add indexing. Our normal built-in functions don’t support indexing (types/generic types actually still need this treatment of not having indexing by default but I haven’t gotten around to fixing that one yet). And of course we try and make sure that all of the extensions that we do offer are only available on an opt-in basis and that opt-in basis is per-module rather than tainting all code in the interpreter. That enables some code to be Python specific and other code to be Ipy specific. That’s done via “import clr” (or importing any other .NET namespace actually) which makes any additional attributes that we’ve added to types available (for example __clrtype__ is not visible until you do an import clr). That enables us to expose things which are .NET specific but still allows pure Python code to run without seeing anything change – so for example if some code as doing dir() it’s not going to freak out because there’s some unexpected attributes. *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Hank Fay *Sent:* Tuesday, May 18, 2010 11:11 AM *To:* Discussion of IronPython *Subject:* [IronPython] .Net attributes/decorators In reviewing the discussion of .Net decorators in the list (thank you Google Groups), I did not come across a discussion of what I saw as the central issue: is IronPython to be a Superset of Python (every Python program will run in IronPython, not every IronPython program will run in Python), or is IronPython to be an equivalent set (every Python program will run in IPy, and every IPy will run in Python). Has there been a discernment on this issue? For me, coming from a non-Python world, it makes sense to view IPy as a superset of Python. This perspective would, e.g., allow the use of .Net decorators on classes (which in turn would facilitate returning .Net objects). I've read about the ways of using __clrtype__ to do this in a Pythonic manner. My interest is in simplicity and clarity in my programs, rather than maintaining two-way compatibility (which I could not port to Python, in any case, for a .Net program using .Net features). thanks, Hank Fay ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] .Net assembly expects array object, sees list
I don't know whether this is a bug or a feature. s I'm using the Advantage ado.net data provider. On the AdsExtendedReader object is a method to Seek a value. The first parameter is supposed to be an array object, .Net type. Here's my code: _myArray = [dProd] _ok = loReader.Seek(_myArray,AdsExtendedReader.SeekType.HardSeek) and here is the result (in 2.6.1003.1), run in SharpDevelop: Microsoft.Scripting.ArgumentTypeException: expected Array[object], got list at Caller.Call at BuiltinFunctionCallerSystem.__Canon,System.__Canon,System.__Canon,System.__Canon,System.__Canon,System.Int32.Call5 at System.Dynamic.UpdateDelegates.UpdateAndExecute7 at IronPython.Runtime.Importer.Import at IronPython.Runtime.Operations.PythonOps.InitializeModule at PythonMain.Main TIA, Hank Fay ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Eventhandling in the IDE: Who is the audience?
In VB, eventhandling can be done by switching to the partial class, selecting the object in the left dropdown at the top of the editor, and then selecting the event in the right dropdown. The function gets created, and of course in VB uses Handles in order to connect the event-handler. This is a style of working with events that is familiar with at least a hundred thousand VFP programmers who have been stranded by MS, and are looking for a way into .Net. And I believe it's familiar with the million plus VB programmers who have not made the switch to .Net (the last figure I read was over 2 million, but that was nearly 2 years ago). I would make the argument that this way of working is straight-forward, involves less typing, and allows clearer thinking: the same kinds of arguments made for Py in general and IPy in particular. I can create a framework that makes working with data, and the IDE, easy for users, and straight-forward in a way that will be familiar to VFP developers -- and am doing so (open source fwiw), hence my special interest in making the rest of the development experience as familiar as possible. So, this is a request. I'll have others, but much of what I need is already in the plan (working with VSX in Python is huge, btw, so thanks in advance for that one). thanks, Hank Fay ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] XAML attribute edit = Unhandled Exception
Maybe this is already known? In IPyTools CTP2: Create new WPF IPY app; add a button; in Button XAML, add MouseEnter= Result: a good chance at this point the unhandled exception will have occurred. If not, this is a 100% occurrence at the next step: enter text between the empty double-quotes after MouseEnter= Pressing the Click here to reload the designer link refreshes the designer OK Here's the stack trace: Server stack trace: at MS.Internal.Providers.VSAssemblyReferenceProvider.AddReference(AssemblyName newReference) at MS.Internal.Host.Isolation.Adapters.ContextToProtocolAdapter.MS.Internal.Host.Isolation.Protocols.IAssemblyReferenceProtocol.AddReference(AssemblyName name) at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[] outArgs) at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData msgData, Int32 type) at MS.Internal.Host.Isolation.Protocols.IAssemblyReferenceProtocol.AddReference(AssemblyName name) at MS.Internal.Host.Isolation.Adapters.ToAssemblyReferenceAdapter.AddReference(AssemblyName newReference) at MS.Internal.Host.PersistenceSubsystem.ReconcileReferences(AssemblyReferences references) at MS.Internal.Host.PersistenceSubsystem.Loadb__8(AssemblyReferences newReferences) at Microsoft.Windows.Design.ContextItemManager.SubscribeProxy`1.SubscribeContext(ContextItem item) at Microsoft.Windows.Design.SubscribeContextCallback.Invoke(ContextItem item) at Microsoft.Windows.Design.EditingContext.DefaultContextItemManager.OnItemChanged(ContextItem item) at Microsoft.Windows.Design.EditingContext.DefaultContextItemManager.SetValue(ContextItem value) at Microsoft.Windows.Design.DocumentModel.MarkupDocumentManagerBase.EnsureAssemblyReference(IAssemblyMetadata assembly) at Microsoft.Windows.Design.DocumentModel.MarkupDocumentManagerBase.ReferenceUpdater.EnsureReferences(IEnumerable`1 types) at Microsoft.Windows.Design.DocumentModel.MarkupDocumentManagerBase.ReferenceUpdater.Microsoft.Windows.Design.DocumentModel.IDocumentTreeConsumer.HandleMessage(DocumentTreeCoordinator sender, MessageKey key, MessageArguments args) at Microsoft.Windows.Design.DocumentModel.MarkupDocumentManagerBase.CancelableDocumentTreeCoordinator.RouteMessage[T](IDocumentTreeConsumer consumer, MessageKey`1 key, T args) at Microsoft.Windows.Design.DocumentModel.DocumentTreeCoordinator.SendMessage[T](MessageKey`1 key, T args, Boolean isPrivateMessage) at Microsoft.Windows.Design.DocumentModel.DocumentTreeCoordinator.SendMessage[T](MessageKey`1 key, T args) at Microsoft.Windows.Design.DocumentModel.DocumentTreeCoordinator.ReportDamage(IDocumentTreeProducer tree, Damage damage) at Microsoft.Windows.Design.DocumentModel.MarkupProducer.Update() at Microsoft.Windows.Design.DocumentModel.MarkupProducer.HandleMessage(DocumentTreeCoordinator sender, MessageKey key, MessageArguments args) at Microsoft.Windows.Design.DocumentModel.MarkupProducer.Microsoft.Windows.Design.DocumentModel.IDocumentTreeConsumer.HandleMessage(DocumentTreeCoordinator sender, MessageKey key, MessageArguments args) at Microsoft.Windows.Design.DocumentModel.DocumentTreeCoordinator.SendMessage[T](MessageKey`1 key, T args, Boolean isPrivateMessage) at Microsoft.Windows.Design.DocumentModel.DocumentTreeCoordinator.QueuedMessage`1.Microsoft.Windows.Design.DocumentModel.IQueuedMessage.Invoke() at Microsoft.Windows.Design.DocumentModel.DocumentTreeCoordinator.ProcessQueuedMessages(Object state) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler) ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Events button?
Not being WPF-fluent in VS, I went to read the very useful WPF Designer for Windows Forms Developers at http://msdn.microsoft.com/en-us/library/cc165605(v=VS.100).aspx. It mentions using the Events button in the Properties page for the object selected in the designer. Which would be fine except that there isn't one. s Nor does right-clicking on the eventhandler name in the XAML lead to a dropdown with a Navigate to Eventhandler etc. option. I assume these are on the development list, but thought I'd check: 40 years ago s we partied for an extra week during an ice storm in Atlanta because no one told the power company that our apartment complex was out. thanks, Hank Fay ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Advantage Database ado.net provider difficulties
I'm trying to use the Advantage Database ado.net provider (9.0.2.7) working in IronPython (2.6.1003.1). OS is Win7 x64; IDE is #develop 4.0.0.5720. I'm getting an error that isn't telling me much. This is based on a C# example I have running on the same machine, in VS2010 RTM. Here's the code (Advantage.Data.Provider.dll is referenced in the project). It blows up on the last line, with the error noted below the code. My hope is that the error will mean more to those with more experience than I and point me in a useful direction. FYI: the code references a directory as a database, and the CommandText selects a field from a DBF that is a free table, that is, not part of a VFP database container (if you were to get the idea that I'm retreading in IP after 24 years developing in xBase languages, you would hit the mark s). import Advantage.Data.Provider from Advantage.Data.Provider import * _conn = Advantage.Data.Provider.AdsConnection(data source=c:\\vpme9apps\next\scaledsardine\versionb\xcase;\ ServerType=local; TableType=CDX) _conn.Open() _cmd = _conn.CreateCommand() _cmd.CommandText = select name from ddent _reader = _cmd.ExecuteReader() And the error: Advantage.Data.Provider.AdsException: System error. at Microsoft.Scripting.Actions.Calls.MethodCandidate+Caller.Call(Object[] args, Boolean shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction+BuiltinFunctionCaller`6[System.Object,System.String,IronPython.Runtime.PythonDictionary,IronPython.Runtime.PythonDictionary,IronPython.Runtime.PythonTuple,System.Int32].Call5(CallSite site, CodeContext context, Object func, String arg0, PythonDictionary arg1, PythonDictionary arg2, PythonTuple arg3, Int32 arg4) at System.Dynamic.UpdateDelegates.UpdateAndExecute7(CallSite site, Object arg0, Object arg1, Object arg2, Object arg3, Object arg4, Object arg5, Object arg6) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references) at PythonMain.Main() tia, Hank Fay ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Advantage Database ado.net provider difficulties
That's even better than a direction: that's the answer! s Thanks, Hank On Tue, Apr 27, 2010 at 11:15 PM, Dino Viehland di...@microsoft.com wrote: My initial guess would be that you want your string literal to be a raw string literal. That is it should have the r prefix such as r”data source=…”. I’m guessing the C# code might have been doing @”data source=…” because of the “\n” in the connection string. *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Hank Fay *Sent:* Tuesday, April 27, 2010 8:09 PM *To:* users@lists.ironpython.com *Subject:* [IronPython] Advantage Database ado.net provider difficulties I'm trying to use the Advantage Database ado.net provider (9.0.2.7) working in IronPython (2.6.1003.1). OS is Win7 x64; IDE is #develop 4.0.0.5720. I'm getting an error that isn't telling me much. This is based on a C# example I have running on the same machine, in VS2010 RTM. Here's the code (Advantage.Data.Provider.dll is referenced in the project). It blows up on the last line, with the error noted below the code. My hope is that the error will mean more to those with more experience than I and point me in a useful direction. FYI: the code references a directory as a database, and the CommandText selects a field from a DBF that is a free table, that is, not part of a VFP database container (if you were to get the idea that I'm retreading in IP after 24 years developing in xBase languages, you would hit the mark s). *import* Advantage.Data.Provider *from* Advantage.Data.Provider *import* * _conn = Advantage.Data.Provider.*AdsConnection*(data source=c:\\vpme9apps\next\scaledsardine\versionb\xcase;\ ServerType=local; TableType=CDX) _conn.*Open*() _cmd = _conn.*CreateCommand*() _cmd.CommandText = select name from ddent _reader = _cmd.*ExecuteReader*() And the error: Advantage.Data.Provider.AdsException: System error. at Microsoft.Scripting.Actions.Calls.MethodCandidate+Caller.Call(Object[] args, Boolean shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction+BuiltinFunctionCaller`6[System.Object,System.String,IronPython.Runtime.PythonDictionary,IronPython.Runtime.PythonDictionary,IronPython.Runtime.PythonTuple,System.Int32].Call5(CallSite site, CodeContext context, Object func, String arg0, PythonDictionary arg1, PythonDictionary arg2, PythonTuple arg3, Int32 arg4) at System.Dynamic.UpdateDelegates.UpdateAndExecute7(CallSite site, Object arg0, Object arg1, Object arg2, Object arg3, Object arg4, Object arg5, Object arg6) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references) at PythonMain.Main() tia, Hank Fay ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython Tools for Visual Studio
I've been getting everyone (relatives including kids, anyone, programming experience not necessary s) I can cajole into going to MS Connect to vote up Michael's issue on the IP IDE in VS. My latest effort is a LInkedIn group for IP, with a permanent discussion item pointing to the Connect issue: http://www.linkedin.com/groups?gid=2989051trk=myg_ugrp_ovr Of course, I would imagine everyone here is one of the nearly 600 now who have voted it up. On Tue, Apr 27, 2010 at 11:17 PM, Dino Viehland di...@microsoft.com wrote: Not yet L We were trying to push through some internal processes for a more optimal release. We’ll release this week whether or not we can push through that part of the process. Sorry for the delay! *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Prasanna Jaganathan *Sent:* Tuesday, April 27, 2010 8:13 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython Tools for Visual Studio Hi Is this available now? Two weeks are up! :-) Prasanna On Thu, Apr 8, 2010 at 11:29 PM, Dino Viehland di...@microsoft.com wrote: It’s not yet publicly available – the preview was given out exclusively to PyCon attendees on a CD. We’ll be putting out an updated version within a couple of weeks after VS 2010 launches which is April 12th. *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Marty Nelson *Sent:* Thursday, April 08, 2010 10:45 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython Tools for Visual Studio We offer extensive Iron Python extension points for our customers in our application and would be very interested in this technology as well. Marty Nelson Symyx Technologies. *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Prasanna Jaganathan *Sent:* Thursday, April 08, 2010 10:36 AM *To:* users@lists.ironpython.com *Subject:* [IronPython] IronPython Tools for Visual Studio Hi I am trying to get a good IDE for working with Iron Python, I chanced upon this page and found about IronPython Tools for Visual Studio. http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_for_Visual_Studio_Walkthrough.pdf I have installed Visual Studio 2010 beta and would like to install this plugin. Can you point me to a place where I can download this? Thank you very much! Regards Prasanna === Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] IronPython and Visual Studio --
An area where IronPython could be especially useful, I think, would be in making dynamic working with the IDE. In Visual Foxpro, with a dialog open, from the Command Window I can issue: Aselobj(aArray) loForm = aArray[1] loForm.height = loForm.height + 50 makes it 50 pixels higher, etc. Making Python the scripting language for the IDE, so that it became dynamic, would put Python in front of many more .Net developers that simply hoping they adopt it because it's a great language (which of course it is s). Ken Levy, who is on the VSData team, actually created a whole system of builders for VFP: he would be a great resource for this project. Hank Fay ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
