Re: [IronPython] Congratulations to Michael Foord on Receiving the Community Service Award

[Hank Fay]

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.   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 wrote:

>  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 
> Foord 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 .
> 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

[Hank Fay]

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-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  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
&g

Re: [IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query?

[Hank Fay]

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

[Hank Fay]

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 weig

Re: [IronPython] .Net attributes/decorators

[Hank Fay]

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. 

thanks again,

Hank

On Tue, May 18, 2010 at 4:50 PM, Dino Viehland  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 Dictionary 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 attributes/decorators

[Hank Fay]

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

Re: [IronPython] .Net assembly expects array object, sees list

[Hank Fay]

Super!  Thanks.  Works.

Hank

On Tue, May 18, 2010 at 12:14 AM, Jimmy Schementi <
jimmy.scheme...@microsoft.com> wrote:

> It’s a feature; the IronPython .Net integration docs show how to go between
> Python lists and .NET arrays (
> http://ironpython.net/documentation/dotnet/dotnet.html#net-arrays):
>
>
>
> System.Array[int]([1, 2, 3])
>
>
>
> Basically you have to be very explicit about providing actual .NET types
> when they are expected.
>
>
>
> ~js
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Hank Fay
> *Sent:* Monday, May 17, 2010 9:09 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] .Net assembly expects array object, sees list
>
>
>
> I don't know whether this is a bug or a feature. 
>
>
>
> 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
> BuiltinFunctionCaller.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
>
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] .Net assembly expects array object, sees list

[Hank Fay]

I don't know whether this is a bug or a feature. 

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
BuiltinFunctionCaller.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

Re: [IronPython] Eventhandling in the IDE: Who is the audience?

[Hank Fay]

The best suggestion I can give is this: have someone show you the VFP9 IDE.
 There are things it doesn't have (code folding e.g.), but things it does
have -- e.g., each method of an object can have it's own editing window, so
you can see 2 or more methods at once.  There's something like it now in
VS2010 from a demo I saw, but it's nowhere as easy to use.

The biggest lack in VS2010 I hope will be addressed when you get to
programming the IDE in IPy.  In VFP, to get the active object in the
designer, as an object, it's a single function: aselobj(), which returns the
object (or objects if multiple selections) in an array.  Those objects can
then be programmed against, adding or setting properties, reading or
inserting code into methods.  It makes creating builders to do scut work
really easy.  Saves on carpal tunnel too.   I hope you have something
like that as a design goal.  I know it can be done: a friend of mine wrote a
version of aselobj() in VS in 2005 (I had been told by certain VFP/VSX team
members that it was impossible, and Frank loves nothing better than a good
challenge, although it took him 2 weeks rather than his customary 2 to 6
hours for significant new features).

The intellisense in VFP was very good, and easily extensible.  It worked
against live objects in the debugger of course, but also against entries the
developer could add, e.g., all the few hundred library routines we created.
 These additional entries are contained where data should be stored, of
course, in a real table , but I guess XML would do, although it's slow
compared to a seek on an indexed table.  So when I type in update_file_ftp(
all the parameters show up, even though there has not been any mention of
the routine in the program, etc.  It's a huge help.  Parenthetically, what
we do is scan all the relevant libraries in a project as startup to see if
there are entries to change or add: that's a trival task when the timestamp
has been kept in the table with the intellisense entry.

Thanks for listening.  I haven't had this experience since the early
(1992-3) Fox days.

Hank







On Wed, May 12, 2010 at 3:58 PM, Dino Viehland  wrote:

>  This is great feedback and I’ve added it to a designer TODO list.  I’ll
> spend some time in the (hopefully near) future going through and improving
> the designer experience.  If you have any other thoughts on things we should
> do in that space (or shouldn’t do J) I’d love to hear it and I’ll add it
> to the list.  Thanks!
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Hank Fay
> *Sent:* Wednesday, May 05, 2010 8:58 PM
> *To:* Discussion of IronPython
> *Subject:* [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
>
>
___
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?

[Hank Fay]

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] Events button?

[Hank Fay]

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.


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  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] XAML attribute edit = Unhandled Exception

[Hank Fay]

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.b__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

Re: [IronPython] IronPython Tools for Visual Studio

[Hank Fay]

I've been getting everyone (relatives including kids, anyone, programming
experience not necessary ) 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=2989051&trk=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  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 
> 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] Advantage Database ado.net provider difficulties

[Hank Fay]

That's even better than a direction: that's the answer! 

Thanks,

Hank

On Tue, Apr 27, 2010 at 11:15 PM, Dino Viehland  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 ).
>
>
>
> *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

[IronPython] Advantage Database ado.net provider difficulties

[Hank Fay]

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 ).

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] IronPython IDE

[Hank Fay]

Works for me in Firefox. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Trimble
Sent: Saturday, December 10, 2005 9:14 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython IDE

On 12/9/05, Aaron Marten <[EMAIL PROTECTED]> wrote:
> Hi Giles,
>I'm on the Visual Studio SDK team here at Microsoft. In 
> co-operation with the IronPython team, we're currently working on 
> integrating IronPython into Visual Studio as a sample to ship in our 
> SDK. We've just released a CTP with the first version of this here:
>
>  http://affiliate.vsipmembers.com/downloads/41/UserFileDownload.ashx

I'd like to check this out, but this URL doesn't seem to be working for me.
It just sits for a while and times out.  Anyone else having problems?

 - Chris
___
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