Hello all.
I am the present maintainer of adodbapi, a pure python module which uses
ADO-DB to access SQL databases. (see adodbapi.sourceforge.net) It has been
my stated goal for some time to port the package to Iron Python, since it is
fully DB-API_2.0 compliant, and the existing SQL access libra
Thanks, Dino. That might help. I hope we can have a DLR compatible
with the framework 3.5 soon.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Ok, I believe I've gotten this to work.I know very little about ASP.NET so
I'm just going to walk through the steps to setup a new Web Site which can use
the DLR. The key limitation here is that if you're referring to a type out of
Microsoft.Scripting.Core.dll you'll need to do it from a .C
we are currently running it on 32 bit OSes only. Windows 2003 and XP.
On Tue, Aug 19, 2008 at 12:42 AM, Dave Fugate <[EMAIL PROTECTED]> wrote:
> Hi everyone, one of the things the IronPython test team does daily is run
> a set of standardized benchmarks against the latest internal build of
> Iro
OK. Thanks a lot. In the meantime, I'll proceed try to modifying the
namespaces in Microsoft.Scripting.Core (if it's actually possible. Hopefully
there's no internal classes being used)
Dody G.
On Tue, Aug 19, 2008 at 9:38 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> I'm continuing to look int
Somewhere around 4 weeks from now.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronnie Maor
Sent: Tuesday, August 19, 2008 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1
nice!
thanks for **kw fix. that was real
nice!
thanks for **kw fix. that was really bugging us.
looks like 2.0b5 is where we'll start seriously looking at switching to 2.0.
do you know when it's expected?
On Tue, Aug 19, 2008 at 7:09 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> The fixes for these (specifically the ones I said I had
I'm continuing to look into it... We're going to have conflicting names
because Microsoft.Scripting.Core includes a superset of the functionality in
the v3.5 System.Core - and changing that would complicate our internal builds
quite a bit. But hopefully we can find a way to get the aliases wor
IronPython for ASP.Net also uses the website model
On Tue, Aug 19, 2008 at 9:22 PM, Dody Gunawinata <[EMAIL PROTECTED]>wrote:
> I can't make it work that way. I'm using the ASP.Net website model.
>
> ASP.Net is blind without either or putting the dll under the
> /bin directory.
>
> There are two
This issue is very bad for my project too. Do you think there is a way
we can make IronPython compatible with the Framework 3.5?
I find it appalling that we even have to consider that...
___
Users mailing list
Users@lists.ironpython.com
http://lists.iron
I can't make it work that way. I'm using the ASP.Net website model.
ASP.Net is blind without either or putting the dll under the
/bin directory.
There are two asp.net application project model in Visual Studio 2008 (it
got introduced in 2005). For the Web Application Project, it has explicit
ref
What if you don't add the assembly in the tag - I don't think that
should be necessary because you're adding it via the command line. And .NET
should still be able to find/load it because it's in the GAC.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dody Gunawinata
Sent: Tues
This is how the web.config refers to the assembly in GAC.
and this is the compiler options
compilerOptions="/reference:DLR=c:\Microsoft.Scripting.Core.dll"
and this is the error.
But can't you leave the assembly in the GAC and have ASP.NET pick it up from
there? It should be that it can be referenced for compilation from one spot
and loaded from the GAC.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dody Gunawinata
Sent: Tuesday, August 19, 2008 10:46 A
Nope. This compiles well but it won't be available for code behind. ASP.Net
can only compiles dll located either on the GAC or under /bin directory.
If I put Microsoft.Scripting.Core under /bin and this option, it will
generate error
"Error10An assembly with the same identity
'Microsoft.S
Ahh, apparently csc can't pick up assemblies out of the gac... :( But you
should be able to copy Microsoft.Scripting.Core.dll anywhere you want and then
reference it. Now that it's in the GAC it should get picked up... So I
believe the final answer should be something like:
/r:DLR="C:\Micro
*I might be doing something wrong*, *but Microsoft.Scripting.Core.dll is
definitely in the GAC.*
(No space)
compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL"
generates
"Error10A /referenc
Have you tried quotes? It should just be getting passed to the command line so
maybe quotes need to be present for the compiler to recognize it correctly - or
maybe just removing the spaces will work.
From: Dody Gunawinata [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2008 10:13 AM
To: Di
hmm..still not working. ASP.Net reads those four qualifier as four
additional assemblies.
Error10Source file 'Version=1.0.0.4000,' could not be found
Error11Source file 'Culture=neutral,' could not be found
Error12Source file 'PublicKeyToken=31bf3856ad364e35,' could not be
Doh! I forgot you probably need to use the fully qualified assembly name -
/reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
From: Dody Gunawinata [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2008
Yikes..
"Error19Metadata file 'Microsoft.Scripting.Core.dll' could not be
found". This is weird.
On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Ok, another thought... can you GAC the DLR assemblies and then add an
> updated
There's an "Operations" property on the ScriptEngine that returns an
ObjectOperations object.
On Tue, Aug 19, 2008 at 9:26 AM, Christian Schmidt <
[EMAIL PROTECTED]> wrote:
> Hi Dino,
>
> Is there a reason ObjectOperations.Call(scope.GetVariable("Process"),
>> args) doesn't work?
>>
>
> It seems
Hi Dino,
Is there a reason ObjectOperations.Call(scope.GetVariable("Process"),
args) doesn't work?
It seems that ObjectOperations does not have a static method Call. Where
do I get an ObjectOperations instance from?
I found another solution:
Delegate process = scope.GetVariable("process")
The fixes for these (specifically the ones I said I had fixes for :) ) are now
checked in and the next source code push (as well as Beta 5) will have the
fixes.
In addition to these issues I've fixed the **kw perf bug recently reported
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?Work
Ok, another thought... can you GAC the DLR assemblies and then add an updated
compilers tag to web.config which includes the alias? Something like:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fernando Correia
Sent: Tuesday, Augu
This is a better approach.
On Tue, Aug 19, 2008 at 6:50 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Is there a reason ObjectOperations.Call(scope.GetVariable("Process"), args)
> doesn't work? Once you have the function in hand you can call using this
> and it takes a params array. That param
Is there a reason ObjectOperations.Call(scope.GetVariable("Process"), args)
doesn't work? Once you have the function in hand you can call using this and
it takes a params array. That params array will be splatted for the call
expanding to however many arguments there are there.
-Original
Hi Dody,
thanks for your patience.
delegate System.Int32 FunctionProcess(System.Int32[] parameters)
This assumes that your Python implement will only do integer operation.
If you are going to use the delegate for generic holder of arguments,
don't forget to cast
for example:
delegate objec
delegate System.Int32 FunctionProcess(System.Int32[] parameters)
This assumes that your Python implement will only do integer operation. If
you are going to use the delegate for generic holder of arguments, don't
forget to cast
for example:
delegate object FunctionProcess(object[] parametser)
py
http://www.c-sharpcorner.com/UploadFile/rambab/Assembly04292006002740AM/Assembly.aspx?ArticleID=69edb807-8118-4933-8366-773e87ee80ad
On Tue, Aug 19, 2008 at 4:50 PM, Christian Schmidt <
[EMAIL PROTECTED]> wrote:
> Hi Dody,
>
> If you are not using this in a .Net 3.5 website project, you can use
Hi Dody,
thanks for your help.
> delegate object FunctionProcess(object[] params);
I've already tried this one and also
delegate object FunctionProcess(params object[] p);
> scope.GetVariable ("Process")
But get an ArgumentException ("Invalid type of return expression value
at 0:0-0:0") here
Hi Dody,
> If you are not using this in a .Net 3.5 website project, you can use
alias to deal with this Beta 4 issue.
I'm not using IP2 in a website project, but would like to use it in a
3.5 project. How do I have to set this alias?
Thanks,
Christian
___
Yeah I wonder about the need to replicate the functions in such a critical
namespace such as System.
Renaming the namespaces is a viable option. My application right now
actually runs on IronPyton for ASP.Net (July 2007 CTP - gasp) and gasp, it
ran on IronPython 2 Alpha and has not been updated ev
We are proud to announce the release of Resolver One, version 1.2 -
still (we think) the largest IronPython application in the world, now
running at 38,000 lines of production code backed up by 150,000 lines of
unit and functional tests.
Resolver One is a Rapid Application Development tool for
Hi Fernando,
Try to build the source yourself and manually refactor the System namespace
in Microsoft.Scripting.Core assembly and deal with anything that blows up.
This is the simplest workaround right now. I'll do that work today because
yeah, my project is tied with this issue as well. I prefer
That's a huge issue for my project. I'm trying to leverage the DLR and
IronPython on a ASP.NET application that targets 3.5. I hope there is
a work-around.
2008/8/19 Dody Gunawinata <[EMAIL PROTECTED]>:
> - This pretty much locks up IronPython 2 from any .Net 3.5 based website.
> The ASP.Net MVC f
If you are not using this in a .Net 3.5 website project, you can use alias
to deal with this Beta 4 issue.
On Tue, Aug 19, 2008 at 2:12 PM, Christian Schmidt <
[EMAIL PROTECTED]> wrote:
> Hi Dody,
>
> scope.GetVariable> ("Process")
>>
>
> The problem is that I do not know the number of arguments
delegate object FunctionProcess(object[] params);
scope.GetVariable ("Process")
and modify your Python code to deal with the object[] params.
On Tue, Aug 19, 2008 at 2:12 PM, Christian Schmidt <
[EMAIL PROTECTED]> wrote:
> Hi Dody,
>
> scope.GetVariable> ("Process")
>>
>
> The problem is that
Hi Dody,
scope.GetVariable> ("Process")
The problem is that I do not know the number of arguments at compile
time but at runtime. So I need something like Func.
Anyway, this would only work if running on framework 3.5, which I can't
because of the problems brought up by Fernando Correia -
scope.GetVariable> ("Process")
On Tue, Aug 19, 2008 at 12:09 PM, Christian Schmidt <
[EMAIL PROTECTED]> wrote:
> Hi Curt,
>
> thanks for your answer. It's an interesting idea, to hand over the items as
> function arguments. I was trying to add them to the ScriptScope.
>
> But I'm still stuck with
Hi Dino,
There's a couple of problems here with this situation:
- This pretty much locks up IronPython 2 from any .Net 3.5 based website.
The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of
System.Core facilities in their code base. The nicest thing about .Net 3.5
is to be
Hi Curt,
thanks for your answer. It's an interesting idea, to hand over the items
as function arguments. I was trying to add them to the ScriptScope.
But I'm still stuck with calling the function:
ScriptScope scope =
ScriptRuntime.Create().GetEngine("py").CreateScope();
scope.Execute("from
Perhaps it's just Vista that's not the future ;-)
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Shechter
Sent: 19 August 2008 08:27
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Informal Poll: measuring IronPython
performanceunder x
I use IP on x64 exclusively since I use it to eventually memory map huge
data-sets (> 2GB) from the disk
To process them.
I agree with Michael Foord. Isn't x64 supposed to be the future or
something?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate
Sent: Tuesday,
Hello guys,
I run IronPython on Vista x64. Isn't 64bit supposed to be the future or
something? :-) (I run Vista x64 in a virtual machine under Mac OS - but
performance is very good. Visual Studio runs quite nicely.)
I'd love to see more IronPython benchmarking (and the results published). Do
you
45 matches
Mail list logo
