Re: [IronPython] ipy support in msxsl:script blocks

Thu, 14 Sep 2006 03:12:04 -0700

Quick update: As per Dr. Kay's latest bug report [http://sourceforge.net/tracker/index.php?func=detail&aid=1558459&group_id=29872&atid=397617 ],

Extension functions on .NET are not working. The
compiler reports that it was unable to find a class
with a matching name.

A late change was made to the URI namespace format used
to identify .NET classes, from the form
type:System.Math to clitype:System.Math. Unfortunately
the code as issued uses the old scheme name "type" in
one place and "clitype" in another. The correct form is
"clitype", and a patch has been placed in Subversion
(module net.sf.saxon.dotnet.DotNetExtensionLibrary) to
correct this.

I am in process of rebuilding Saxon and Saxon on .NET from source (need to update my local nant script to accomodate some changes), and once complete, will finish out the second half of this demo and get it posted.


On 9/6/06, M. David Peterson <[EMAIL PROTECTED]> wrote:
Excellent!  Thanks for the advice, Dino!  I will add this to my priority list and update accordingly.
 
In a (somewhat) related note, I have been pulling together a quick demo that incorporates IronPython, LINQ, and XSLT 2.0 extensions functions to provide what I believe will prove to be an extremely lethal combination as this demo develops.  The first part is complete, though a bit rough around the edges.
 
This builds directly from < http://www.oreillynet.com/xml/blog/2006/08/solving_some_of_scobles_proble.html > from a few weeks back.  The post was an XSLT 2.0 answer to Steve Eichert's "Solving Scoble's problems ..." < http://steve.emxsoftware.com/LINQ/Solving+all+Scobles+problems+with+Linq+to+XML > post from a few weeks back.  However, this time around I have extended Steve's original code base < http://dev.pypod.net/browser/trunk/LINQModules/FeedFilter.cs > to implement a slight more dynamic approach to the filter settings such that you can add, subtract, multiply, and/or divide the filter settings using an external XML file.
 
I have quite a bit more to add to this, including the mentioned extension functions for XSLT 2.0.  More updates throughout today and tomorrow, the result of which will become a new post when complete. However, I'll avoid flooding the list with each update, and instead point you to the timeline RSS < http://dev.pypod.net/timeline?ticket=on&changeset=on&milestone=on&wiki=on&wiki=on&max=50&daysback=90&format=rss > feed if you have interest in keeping up with the changes. 
 
With this in mind, if any of you have some ideas you would like to throw my direction, or furthermore would like to view/play with the code base, you can do so via the PyPod.Net Click-Once app, or checkout the code base from SVN directly.
 
The svn repo is located @ http://src.pypod.net/trunk
 
You can view the code base via the Trac interface @ http://dev.pypod.net/browser/trunk
 
And, as already mentioned in a separate thread, the PyPod.Net app is located @,
 
 
To run the (BIG TIME HACK) test,
 
>>> import linqtest
 
(note: Dependent upon your system, you may get a "SystemError: Unable to connect to the remote server" error at first of which you will then more than likely be asked for permission for the IP Console to access the internet)
 
As pointed out, the above is a quick and dirty hack just to test and make sure it works properly.  I am in the middle of building a more efficient caching mechanism such that the XML data for processing can be accessed once, cached locally, and then used for each subsequent test run unless a flag is set to access the live stream again.  WIth this in mind, please be aware that the XML data file that is currently set to be accessed dynamically with each new run is ~17megs, so it will take a bit before you see the result of the filtering printed to the console.
 
I'll update with extended details when it seems appropriate to do so.
 
Until then, please let me know of any ideas any of you would like to see developed as part of this code base.  Sample code is all fine and dandy, but I would rather write something that would be immediatelly useful and reusable to a broader base of folks than would be your typical sample app if at all possible.
 
Best regards,

 
On 9/6/06, Dino Viehland <[EMAIL PROTECTED] > wrote:

The best thing you could do for Saxon.NET right now is to support ICustomTypeDescriptor in addition to supporting Reflection.  The one downside is that ICustomTypeDescriptor isn't as comprehensive as Reflection.Emit – for example it doesn't support calling methods.  But it does support getting properties.  So you'll want to back that up w/ Reflection, and hopefully in time there'll be a solution which will encompass all of these.

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of M. David Peterson
Sent: Tuesday, September 05, 2006 2:27 PM
To: Discussion of IronPython
Subject: Re: [IronPython] ipy support in msxsl:script blocks

 

btw, the newly released docs in regards to develping extension functions for Saxon on .NET are located @ http://www.saxonica.com/documentation/extensibility/dotnetextensions.html

On 9/5/06, M. David Peterson <[EMAIL PROTECTED]> wrote:

Worth noting, from my post earlier today ( http://www.oreillynet.com/xml/blog/2006/09/mhksaxon_saxon_88basic_and_sch_1.html ) regarding the release of Saxon on .NET 8.8,

* in the .NET product, extension functions written in C# or other .NET

 languages can now be invoked


While the same is more than likely true in regards to the ability to access extension functions written in Python, this is one area I can help with more so than anything else as this was a significant area of study and development I put into Saxon.NET before handing over the reigns to Dr. Kay in February.   In addition, with his guidance, I've since continued forward in working on various areas of research and development.  With this in mind, in regards to,

 

We'll need to work w/ some other teams within the company to make sure we can get the right amount of support in the right places to make this all come together.  Thanks for bringing this to our attention.

 

While for obvious reasons I can't help with the internal System.Xml.Xsl code base, I can help with the Saxon.NET code base.  If I can be of help, please let me know :)



On 9/5/06, Dino Viehland < [EMAIL PROTECTED]> wrote:

The answer to this appears to be no - The XSL processor uses Reflection to try and discover the method to be called.  In IronPython reflection won't tell you what methods are available.  We do support the ICustomTypeDescriptor interface which is another way to get this information (which enables scripting WPF), but unfortunately XSL isn't falling back to that.

We'll need to work w/ some other teams within the company to make sure we can get the right amount of support in the right places to make this all come together.  Thanks for bringing this to our attention.  I'm not going to open a bug on this (because it's not necessarily an IP issue) but I believe we will be tracking this one (and similar issues) closely.


From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Jesse Wiles
Sent: Tuesday, September 05, 2006 8:00 AM
To: Discussion of IronPython
Subject: [IronPython] ipy support in msxsl:script blocks

Hi,

Can I script XSL extension objects using Iron Python?

Jesse Wiles
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com






--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354


_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com





--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354



--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to