Re: [IronPython] Question for Sanghyeon Seo on porting projects
And catching up on the discussion here is a procrastination for me -- an enjoyable one to be sure, but it doesn't get me anywhere (like to bed!). At 12:16 PM 9/12/2006, Sanghyeon Seo wrote (in part) A possible solution to the current blocker is to stop procrastinating, which is known to be extraordinarily difficult. J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ScrollBarsEnabled problem
At 01:45 PM 9/12/2006, Dino Viehland wrote This might be a better question on a newsgroup specific to .NET or the IE web control. Adding the ScrollBarsEnabled = False is the same as doing: WebBrowser1 = WebBrowser() WebBrowser1.ScrollBarsEnabled = True Shouldn't that be = False??? [snip] J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] A SourceForge project?
Sanghyeon Seo wrote: (CodePlex is no-no for me, I don't have TFS client.) Team Explorer client is available for CodePlex use. -- sig://boB http://bobs.org ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ScrollBarsEnabled problem
Yeh, it should. But even then, it still displays the scrollbar when viewing certain sites. I found out that it has something to do with sites with frames. When I navigate to a site with frames, it displays the scrollbars, and when I navigate to a site without frames, it doesn't display them. But I still don't know how to disable scrollbars in a site with frames. Floris On 9/15/06, J. Merrill [EMAIL PROTECTED] wrote: At 01:45 PM 9/12/2006, Dino Viehland wroteThis might be a better question on a newsgroup specific to .NET or the IE web control.Adding the ScrollBarsEnabled = False is the same as doing: WebBrowser1 = WebBrowser()WebBrowser1.ScrollBarsEnabled = TrueShouldn't that be = False???[snip]J. Merrill / Analytical Software Corp___ users mailing listusers@lists.ironpython.comhttp://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] More patches
More patches: http://sparcs.kaist.ac.kr/~tinuviel/fepy/patches/ patch-ironpython-empty-apply This patches fixes an issue that apply builtin function doesn't accept a single argument. patch-ironpython-open-unknown-mode This patch lets IronPython to ignore unknowm mode characters in open builtin function. -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote:
We're tentatively thinking that this is a 2.0 feature but if we figured out a
syntax we really liked we'd try to get it into 1.1.
It seems as if there are two clean ways to do this in my mind.
1. Use python2.4's decorator sytax and extend it to allow class and
class variable attribute declaration. This has the pitfall of
breaking cpython compatibility with decorators though. At the same
time, why use decorators when you can use attributes?
2. Thinking about this problem brings me back to an elegant solution
that Philip Eby came up with to allow python2.3 users to use
decorators for turbogears.
class Root:
[expose()]
def method(): ...
Granted special logic has to be added to the decorator method. This
prompted me to try:
import clr
clr.AddReference('System.Web.Services')
from System.Web.Services import *
[WebServiceAttribute]
class Echo(WebService):
[WebMethodAttribute]
def echo(msg):
return msg
The advantage here is syntactically correct python. IP could just add
some special logic to apply the attributes. Another advantage is that
it matches the sytax of C# attributes. Evil programmers could even
apply decorators and attributes to a method!
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote:
On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote:
We're tentatively thinking that this is a 2.0 feature but if we figured out
a syntax we really liked we'd try to get it into 1.1.
It seems as if there are two clean ways to do this in my mind.
1. Use python2.4's decorator sytax and extend it to allow class and
class variable attribute declaration. This has the pitfall of
breaking cpython compatibility with decorators though. At the same
time, why use decorators when you can use attributes?
When this was last discussed on Python-Dev, Guido agreed that class
decorators could go into core Python. (Partly because of the IronPython
usecase.)
The best thing to do (IMHO) is to see if a syntax can be agreed on
Python-Dev, to ensure future compatibility with CPython.
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
2. Thinking about this problem brings me back to an elegant solution
that Philip Eby came up with to allow python2.3 users to use
decorators for turbogears.
class Root:
[expose()]
def method(): ...
Granted special logic has to be added to the decorator method. This
prompted me to try:
import clr
clr.AddReference('System.Web.Services')
from System.Web.Services import *
[WebServiceAttribute]
class Echo(WebService):
[WebMethodAttribute]
def echo(msg):
return msg
The advantage here is syntactically correct python. IP could just add
some special logic to apply the attributes. Another advantage is that
it matches the sytax of C# attributes. Evil programmers could even
apply decorators and attributes to a method!
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
We're tentatively thinking that this is a 2.0 feature but if we figured out a syntax we really liked we'd try to get it into 1.1. It seems as if there are two clean ways to do this in my mind. 1. Use python2.4's decorator sytax and extend it to allow class and class variable attribute declaration. This has the pitfall of breaking cpython compatibility with decorators though. At the same time, why use decorators when you can use attributes? When this was last discussed on Python-Dev, Guido agreed that class decorators could go into core Python. (Partly because of the IronPython usecase.) The best thing to do (IMHO) is to see if a syntax can be agreed on Python-Dev, to ensure future compatibility with CPython. I agree. A proof of concept that demonstrates the use of class decorators might help them decide. -H. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote: We're tentatively thinking that this is a 2.0 feature but if we figured out a syntax we really liked we'd try to get it into 1.1. It seems as if there are two clean ways to do this in my mind. 1. Use python2.4's decorator sytax and extend it to allow class and class variable attribute declaration. This has the pitfall of breaking cpython compatibility with decorators though. At the same time, why use decorators when you can use attributes? When this was last discussed on Python-Dev, Guido agreed that class decorators could go into core Python. (Partly because of the IronPython usecase.) What about class variables, properties, etc? The AttributeTargets enum lists many options. I don't see cpython allowing decorators on properties. Also, decorators and attributes are different beasts. Allowing their syntax to be the same would make it difficult to distingush which way it should be used. I personally think attribute support should trump decorator support in IP. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote: On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote: We're tentatively thinking that this is a 2.0 feature but if we figured out a syntax we really liked we'd try to get it into 1.1. It seems as if there are two clean ways to do this in my mind. 1. Use python2.4's decorator sytax and extend it to allow class and class variable attribute declaration. This has the pitfall of breaking cpython compatibility with decorators though. At the same time, why use decorators when you can use attributes? When this was last discussed on Python-Dev, Guido agreed that class decorators could go into core Python. (Partly because of the IronPython usecase.) What about class variables, properties, etc? The AttributeTargets enum lists many options. I don't see cpython allowing decorators on properties. Also, decorators and attributes are different beasts. Allowing their syntax to be the same would make it difficult to distingush which way it should be used. I personally think attribute support should trump decorator support in IP. Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... David ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Also attributes being classes and decorators functions might help. I agree it is better to allow the decorator syntax in more places than cpython than the alternative. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Adding methods in hosting application during runtime
Still working on integrating ironPython in a web application and just tryed to do some ajax stuff with AjaxPro. Duriing implementation i realized that i can't use AjaxPro like the way i do it in c# or vb. not at least of the problem with the method attributes but the real problem is the matter of fact that objects i created in the python enviroment aren't available by ajaxpro because the generated html script looks like this script type=text/javascript src=/webapp/ajaxpro/IronPython.NewTypes.System.Object_1,snippets1.ashx/script ...and this thing does not exist :( I think a nice way would be to extend the hosting application with some objects they life next to all classic .NET objects so that a external caller could not see a difference. But this wouldn't work because the hosting app isn't dynamic, or does it? One thought was to use IronPython.Compiler to create a 'real' assembly and then load it into the hosting application but that sounds a little bit strange. So my question is : Is it possible to create objects in the hosting application from a python script that are callable from extern by reflection (i think ajaxpro does it by reflection) ? If i'm absolutly on the wrong way to relize this let me know. thanks, bernd -- View this message in context: http://www.nabble.com/Adding-methods-in-hosting-application-during-runtime-tf2277947.html#a6326609 Sent from the IronPython forum at Nabble.com. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Michael Foord http://www.voidspace.org.uk/python/index.shtml I agree it is better to allow the decorator syntax in more places than cpython than the alternative. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Callable classes I suppose ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote:
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote:
Charlie Moad wrote:
Take away decorator support and you'll lose at least this Python
programmer...
Decorators and attributes have at least some commonality, which is why
this syntax ended up in Python in the first place...
Allowing decorator syntax in places CPython doesn't is better than not
allowing it where it does...
So it sounds like people want decorator syntax for attributes. Would
it be sufficient to check for inheritance from System.Attribute to
distinguish the two?
Sounds very good.
Also attributes being classes and decorators
functions might help.
Can't CPython decorators also be classes (I haven't tried this) ?
Callable classes I suppose
You mean instances...
I meant something like this, which works in CPython and is a good way of
implementing the descriptor protocol :
class DecoratorClass(object):
def __init__(self, function):
self.function = function
def __call__(self, *args, **keywargs):
print 'called'
return self.function(*args, **keywargs)
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
@DecoratorClass
def function(*args):
print args
function('hello')
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote:
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote:
Charlie Moad wrote:
Take away decorator support and you'll lose at least this Python
programmer...
Decorators and attributes have at least some commonality, which is why
this syntax ended up in Python in the first place...
Allowing decorator syntax in places CPython doesn't is better than not
allowing it where it does...
So it sounds like people want decorator syntax for attributes. Would
it be sufficient to check for inheritance from System.Attribute to
distinguish the two?
Sounds very good.
Also attributes being classes and decorators
functions might help.
Can't CPython decorators also be classes (I haven't tried this) ?
Callable classes I suppose
(Oops... put my sig in the middle of the code.)
You mean instances...
I meant something like this, which works in CPython and is a good way of
implementing the descriptor protocol :
class DecoratorClass(object):
def __init__(self, function):
self.function = function
def __call__(self, *args, **keywargs):
print 'called'
return self.function(*args, **keywargs)
@DecoratorClass
def function(*args):
print args
function('hello')
Provide '__get__' and friends to implement the descriptor protocol on a
function. My guess is that this is pretty much how class methods become
bound methods on instances.
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Ann: GUI Editor for IronPython
Added IronPython to the supported GUI languages in FarPy GUIE- http://farpy.holev.com/tools.php About- GUIE (GUI Editor) provides a simple WYSIWYG GUI editor for wxWidgets. The program was made in C# and saves the GUI that was created to a XML format I called GUIML. This GUIML is a pretty standard representation of the GUI created with the program with some helpful additions for .NET. Next, GUIE takes these GUIML files and translates it to either wxPython Python code or wxRuby Ruby code (more languages in the future). You may ask yourself why I took the extra step? Why didn't I go straight from C# controls to wxPython code? Why is GUIML necessary? Well, it isn't. It is there simply for people (or maybe I) to take the GUIML and convert it to other languages. This, by effect can convert this tool from a Python GUI editor, to any programming language with a GUI module GUI editor. The tools is open source under the GPL license. Thanks, David http://farpy.holev.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ann: GUI Editor for IronPython
holev wrote: Added IronPython to the supported GUI languages in FarPy GUIE- http://farpy.holev.com/tools.php Does this generate code for wx.NET ? Michael Foord http://www.voidspace.org.uk/python/index.shtml About- GUIE (GUI Editor) provides a simple WYSIWYG GUI editor for wxWidgets. The program was made in C# and saves the GUI that was created to a XML format I called GUIML. This GUIML is a pretty standard representation of the GUI created with the program with some helpful additions for .NET. Next, GUIE takes these GUIML files and translates it to either wxPython Python code or wxRuby Ruby code (more languages in the future). You may ask yourself why I took the extra step? Why didn't I go straight from C# controls to wxPython code? Why is GUIML necessary? Well, it isn't. It is there simply for people (or maybe I) to take the GUIML and convert it to other languages. This, by effect can convert this tool from a Python GUI editor, to any programming language with a GUI module GUI editor. The tools is open source under the GPL license. Thanks, David http://farpy.holev.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Unfortunately, CPython only allows the decorator syntax before a function declaration... You could always manually call the decorator function w/ the class object and see what you get back though. Charlie's earlier point about all the different targets is a really good one though - worse than even properties are things like arguments, return types, etc... that won't fit in at all w/ decorators. You could imagine allowing the syntax anywhere, but there'd be no way to disambiguate between a return decorator and a function decorator in Python. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Moad Sent: Friday, September 15, 2006 7:46 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Callable classes I suppose ___ 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] Descriptor/metaclass problems
Filed as CodePlex issue # 3287 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Stephenson Sent: Thursday, September 14, 2006 4:56 PM To: Discussion of IronPython Subject: [IronPython] Descriptor/metaclass problems Hi, The following code works perfectly in CPython, but is all over the shop in ipy :-( Any ideas on how I might make it work in ipy? class valueDescriptor(object): def __init__(self,x=None): self.value = x def __get__(self,ob,cls): return self.value def __set__(self,ob,x): self.value = x class Ameta(type): def createShared( cls, nm, initValue=None ): o = valueDescriptor(initValue) setattr( cls,nm, o ) setattr( cls.__class__,nm, o ) class A: __metaclass__ = Ameta class B( A ): A.createShared(cls2,1) def show(): # all outputs should be the same!! print o.cls2 print o2.cls2 print A.cls2 print B.cls2 o = A() o2 = B() show() B.cls2 = 2 show() A.cls2 = 3 show() o.cls2 = 4 show() o2.cls2 = 5 show() ___ 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] socket for IronPython update
Is there a reason not to pick up Seo's version? His license (do whatever ... you want) would certainly allow it. Is the wheel he built not round enough? At 11:40 AM 9/11/2006, Dino Viehland wrote Originally we were trying to implement _socket instead of socket. We ran into one problem with this: the standard socket.py module has an implicit dependency upon CPython's reference counting garbage collector (for implementing dup). We considered a hack to make this work but ultimately rejected it in favor of implementing socket instead replacing the standard Python module. Unfortunately makefile didn't make it - and that looks like the same thing for ssl (it's present in CPythons socket but not _socket). Select was a much simpler case of just not getting to it in time. We'll ship a select implementation w/ the 1.1 release - we'll need to look at makefile ssl though (makefile should be trivial, hopefully ssl will be just as trivial). J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] socket for IronPython update
Unfortunately we cannot currently accept changes back into the IronPython core right now. :( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill Sent: Friday, September 15, 2006 9:58 AM To: Discussion of IronPython Subject: Re: [IronPython] socket for IronPython update Is there a reason not to pick up Seo's version? His license (do whatever ... you want) would certainly allow it. Is the wheel he built not round enough? At 11:40 AM 9/11/2006, Dino Viehland wrote Originally we were trying to implement _socket instead of socket. We ran into one problem with this: the standard socket.py module has an implicit dependency upon CPython's reference counting garbage collector (for implementing dup). We considered a hack to make this work but ultimately rejected it in favor of implementing socket instead replacing the standard Python module. Unfortunately makefile didn't make it - and that looks like the same thing for ssl (it's present in CPythons socket but not _socket). Select was a much simpler case of just not getting to it in time. We'll ship a select implementation w/ the 1.1 release - we'll need to look at makefile ssl though (makefile should be trivial, hopefully ssl will be just as trivial). J. Merrill / Analytical Software Corp ___ 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] .NET attributes
Charlie's earlier point about all the different targets is a really good one though - worse than even properties are things like arguments, return types, etc... that won't fit in at all w/ decorators. You could imagine allowing the syntax anywhere, but there'd be no way to disambiguate between a return decorator and a function decorator in Python. By using attribute-target specifiers? (type, property, param, field, etc.) -H. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ScrollBarsEnabled problem
I pinged a friend who's infinitely more web savvy than I, he suggested trying to do document.body.scroll = no; in the document - although he wasn't entirely sure if that'd work. That'll require access to the DOM somehow - hopefully you can access the DOM through the web browser interfaces. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Floris van Nee Sent: Friday, September 15, 2006 1:23 AM To: Discussion of IronPython Subject: Re: [IronPython] ScrollBarsEnabled problem Yeh, it should. But even then, it still displays the scrollbar when viewing certain sites. I found out that it has something to do with sites with frames. When I navigate to a site with frames, it displays the scrollbars, and when I navigate to a site without frames, it doesn't display them. But I still don't know how to disable scrollbars in a site with frames. Floris On 9/15/06, J. Merrill [EMAIL PROTECTED] wrote: At 01:45 PM 9/12/2006, Dino Viehland wrote This might be a better question on a newsgroup specific to .NET or the IE web control. Adding the ScrollBarsEnabled = False is the same as doing: WebBrowser1 = WebBrowser() WebBrowser1.ScrollBarsEnabled = True Shouldn't that be = False??? [snip] J. Merrill / Analytical Software Corp ___ 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] socket for IronPython update
Dino Viehland wrote: Unfortunately we cannot currently accept changes back into the IronPython core right now. :( Not at all? What are the issues? David ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] socket for IronPython update
Sorry, I wasn't clear. I was referring to this for 1.1. Or are you saying that some part of the licensing / legalistic stuff that goes on (invisibly to many of us) means that you can't put any outsider contributions into what you ship? At 01:02 PM 9/15/2006, Dino Viehland wrote Unfortunately we cannot currently accept changes back into the IronPython core right now. :( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill Sent: Friday, September 15, 2006 9:58 AM To: Discussion of IronPython Subject: Re: [IronPython] socket for IronPython update Is there a reason not to pick up Seo's version? His license (do whatever ... you want) would certainly allow it. Is the wheel he built not round enough? At 11:40 AM 9/11/2006, Dino Viehland wrote Originally we were trying to implement _socket instead of socket. We ran into one problem with this: the standard socket.py module has an implicit dependency upon CPython's reference counting garbage collector (for implementing dup). We considered a hack to make this work but ultimately rejected it in favor of implementing socket instead replacing the standard Python module. Unfortunately makefile didn't make it - and that looks like the same thing for ssl (it's present in CPythons socket but not _socket). Select was a much simpler case of just not getting to it in time. We'll ship a select implementation w/ the 1.1 release - we'll need to look at makefile ssl though (makefile should be trivial, hopefully ssl will be just as trivial). J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ScrollBarsEnabled problem
Ah ok, but my next question would be then, how would I do that in IronPython with the WebBrowser. They seem to have disabled it there. It only works with AxWebBrowser, but I can't acces that in IronPython. Does anyone of you know that? Floris On 9/15/06, Dino Viehland [EMAIL PROTECTED] wrote: I pinged a friend who's infinitely more web savvy than I, he suggested trying to do document.body.scroll = no; in the document - although he wasn't entirely sure if that'd work.That'll require access to the DOM somehow - hopefully you can access the DOM through the web browser interfaces. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Floris van Nee Sent: Friday, September 15, 2006 1:23 AMTo: Discussion of IronPythonSubject: Re: [IronPython] ScrollBarsEnabled problemYeh, it should. But even then, it still displays the scrollbar when viewing certain sites. I found out that it has something to do with sites with frames. When I navigate to a site with frames, it displays the scrollbars, and when I navigate to a site without frames, it doesn't display them. But I still don't know how to disable scrollbars in a site with frames.FlorisOn 9/15/06, J. Merrill [EMAIL PROTECTED] wrote:At 01:45 PM 9/12/2006, Dino Viehland wrote This might be a better question on a newsgroup specific to .NET or the IE web control.Adding the ScrollBarsEnabled = False is the same as doing:WebBrowser1 = WebBrowser()WebBrowser1.ScrollBarsEnabled = TrueShouldn't that be = False???[snip]J. Merrill / Analytical Software Corp___users mailing list users@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com___ users mailing listusers@lists.ironpython.comhttp://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] Trying (unsuccessfully) to subclass Gtk.Widget class
Hello, I'm running IPython 1.0 on mono on Linux. I'm importing the gtk-sharp dll and I want to subclass the Gtk.Widget class (http://www.go-mono.com/docs/[EMAIL PROTECTED]). Here is my script: clr.AddReference(gtk-sharp) clr.AddReference(gnome-sharp) from Gtk import * from Gnome import * Application.Init() class Table: pass class Sheet(Widget): def __init__(self, table): Widget.__init__(self) Here is my ipy session where I try to use Sheet IronPython 1.0.2432 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. import sheet from sheet import * t = Table() s = Sheet(t) Traceback (most recent call last): TypeError: no overloads of Sheet could match (type, Table) Sheet(type, IntPtr) Sheet(type, GType) It tells me it can't find an appropriate overload for Sheet and then gives me what looks like the only two possible candidates. However, the candidates it lists looks like they are from the parent class Widget. Does IronPython hava a constraint that the __init__ method must take the same parameters as the parent class? Here is the list of constructors for Widget: http://www.go-mono.com/docs/[EMAIL PROTECTED] If I remove the parameter from __init__ it works. I've tested this scenario with made up classes and it works. CPython documentation seems to indicate that a child class can have different parameters on its __init__method then the parent class. Any help? Is there something wrong with the gt-sharp library (I don't think so, as I could write a C# app that did this same thing and it worked). I'm convinced this must be user-error and I'm just not seeing the problem Thanks, Michael ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] socket for IronPython update
Isn't that what Seo's Community Edition is for? Obviously not the official MSFT edition, but it certainly does the trick.On 9/15/06, J. Merrill [EMAIL PROTECTED] wrote:Sorry, I wasn't clear.I was referring to this for 1.1.Or are you saying that some part of the licensing / legalistic stuff that goes on (invisibly to many of us) means that you can't put any outsider contributions into what you ship?At 01:02 PM 9/15/2006, Dino Viehland wrote Unfortunately we cannot currently accept changes back into the IronPython core right now. :(-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of J. MerrillSent: Friday, September 15, 2006 9:58 AMTo: Discussion of IronPythonSubject: Re: [IronPython] socket for IronPython update Is there a reason not to pick up Seo's version?His license (do whatever ... you want) would certainly allow it.Is the wheel he built not round enough?At 11:40 AM 9/11/2006, Dino Viehland wrote Originally we were trying to implement _socket instead of socket.We ran into one problem with this: the standard socket.py module has an implicit dependency upon CPython's reference counting garbage collector (for implementing dup).We considered a hack to make this work but ultimately rejected it in favor of implementing socket instead replacing the standard Python module. Unfortunately makefile didn't make it - and that looks like the same thing for ssl (it's present in CPythons socket but not _socket). Select was a much simpler case of just not getting to it in time.We'll ship a select implementation w/ the 1.1 release - we'll need to look at makefile ssl though (makefile should be trivial, hopefully ssl will be just as trivial). J. Merrill / Analytical Software Corp___users mailing listusers@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com-- /M:DM. David Petersonhttp://mdavid.name | http://www.oreillynet.com/pub/au/2354 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Dino Viehland wrote: Unfortunately, CPython only allows the decorator syntax before a function declaration... You could always manually call the decorator function w/ the class object and see what you get back though. Charlie's earlier point about all the different targets is a really good one though - worse than even properties are things like arguments, return types, etc... that won't fit in at all w/ decorators. You could imagine allowing the syntax anywhere, but there'd be no way to disambiguate between a return decorator and a function decorator in Python. It's uglier, but what about providing built in functions for applying attributes. A specific built-in could apply return attributes etc. This at least avoids the problem of adding a syntax that is incompatible with CPython. Michael Foord http://www.voidspace.org.uk/python/index.shtml -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Moad Sent: Friday, September 15, 2006 7:46 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Callable classes I suppose ___ 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 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ann: GUI Editor for IronPython
holev wrote: Added IronPython to the supported GUI languages in FarPy GUIE- http://farpy.holev.com/tools.php 2006/9/16, Michael Foord [EMAIL PROTECTED]: Does this generate code for wx.NET ? I had a look at the source code. It generates code for Windows Forms. Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
