From elguavas@users.sourceforge.net Sat Aug 3 07:11:46 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 03 Aug 2002 16:11:46 +1000 Subject: [Idle-dev] Re: IDLE UI Suggestion In-Reply-To: References: Message-ID: <1028355107.528.31.camel@oberon> On Sat, 2002-08-03 at 03:33, unknown man wrote: > > I saw from the IDLEfork Website That you are the person in charge of most > of the changes to IDLE and IDLEfork's UI. I'm the project manager, or coordinator, for idlefork only. As it is a cooperative open-source development project I don't have any 'power' to tell anyone to do anything (nor would I want it), I just happen to be the one who's volunteered some time to try to keep the project on the rails as well as do some hacking on it. As for idle itself, as part of python it is completely up to Guido van Rossum what happens with it, although he has indicated that many of the features we are currently developing in idlefork may well make it into a future idle version. > I have a few suggestions for > IDLE UI. I'm Not submitting them to the feature request area because > I've noticed that that is often ignored by the IDLEfork Developers. If you're talking about idlefork feature requests, nothing there is ignored, but feature requests that are not in the project's current scope (see http://idlefork.sourceforge.net/tasks.php ) will only be looked at in detail when we are much closer to being stable for the next series of releases. Of course if someone wants to dontate the time to work on some whole new area along with the idea for it, that may be a different question. > (I'm not blaming anybody for this because you only have five register > developers right now.) Also don't forget that any developers listed on any sourceforge project page are not necessarily all that active at all times. > I have ranked them using a one star (*) to > five star (*****) System. I hope you can quickly change #1 and have > the BDFL approve it Sorry I don't know what BDFL is. > because it not only causes the program to crash in > some cases but it also scares some new python user's from using IDLE. > > ***** > #1. The menu items that do not apply to the python shell window (These > should be pretty obvious) soul be disabled or removed for the python > shell window. I'm pretty sure Kurt Kaiser has recently checked in some changes along these lines, plus if I remember rightly I recently tracked some changes from python idle cvs that were already to this effect. > ** > #2. If possible remove the standard Tk icon from the window and replace > it with one of the python icons. It would make IDLE look more > official. This is purely a Tk issue, not even a python one let alone an idle or idlefork one. The Tk toolkit (whether or not it is called from python) _insists_ on using it's own 'Tk' window icon under windows. Maybe they will change this in the soon to be released Tk 3.4, I don't know, you could follow it up in the Tk newsgroups/mailing lists if you like. Not that there is any such issue under linux or any of the other unix-like platforms that Tk/python/idle/idlefork run on; it only affects windows. I agree that it looks pretty ugly though. > Thank you for your time. No worries, thanks for you interest in idlefork. I will forward this reply to your message to the idle-dev mailing list, since this is the place where issues relating to idle and idlefork are discussed. If you have any further suggestions and don't want to use the sourceforge tracker I suggest you join the idle-dev list ( http://mail.python.org/mailman/listinfo/idle-dev ) and post your ideas there. Regards, Stephen M. Gava -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From elguavas@python.net Sat Aug 3 07:20:35 2002 From: elguavas@python.net (Stephen M. Gava) Date: 03 Aug 2002 16:20:35 +1000 Subject: [Idle-dev] massive cruftectomy In-Reply-To: <012701c2366f$a20e2160$0b01000a@reston01.va.comcast.net> References: <1027558287.10870.24.camel@oberon> <012701c2366f$a20e2160$0b01000a@reston01.va.comcast.net> Message-ID: <1028355635.523.40.camel@oberon> gvanrossum wrote: > > The modules in question are: FrameViewer.py, loader.py, > > MultiScrolledLists.py, Remote.py, RemoteInterp.py, Separator.py, and > > ToolTip.py . > > > > If you've had any connection with idlefork or idle in the past please > > cast an eye over that list and let me know if you think any of those > > modules still need to be in idlefork. > > I think all of these can go. Here are my comments: > > FrameViewer.py: probably a very early experiment of mine in GUI tools. [...] > Separator.py: part of MultiScrolledLists.py Thanks for the reply Guido, I'm glad to see it fits in with the 'executive decision' I was about to make on these modules anyway. 8^) As for this one: > ToolTip.py: this might be handy, it's an attempt at creating a generally > useful tooltip feature. But maybe there's another approach to that > already? (CallTips doesn't seem to use this.) calltips doesn't use it, but calltips does have a comment indicating that it is based on the same code. I also think it could be handy sometime for other purposes, so I might just add a comment to the module to that effect and leave it in with the other source at this stage. Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From noaaam@hotmail.co.il Sat Aug 3 23:52:30 2002 From: noaaam@hotmail.co.il (Noam Raphael) Date: Sun, 4 Aug 2002 01:52:30 +0300 Subject: [Idle-dev] (no subject) Message-ID: <88D43EB4F24B07846A957665B36F752B@noaaam.hotmail.co.il> Hello! I've downloaded IDLE and IDLEfork and it looks as a very cool thing. The main thing I'm missing is expantion not according to text which was already displayed, but according to the object's real attributes. I looked a bit on the source code of CallTip and to me it looks possible to write an extension that will do this expantion in visual C++ style. What I think of is that when a '.' is entered, a list of attributes will open, which will scroll itself according to what's written, 'up' and 'down' keys will scroll it manually, and, say, the 'tab' key will complete what's written according to what's selected in the list. Were any attempts made to write such a thing? If not, I may try to do it myself, but in at least a month as I'm currently quite busy. Keep on the good work! Noam =F0=F9=EC=E7 =F2"=E9 =EE=F9=FA=EE=F9 Hotmail =E1=F2=E1=F8=E9=FA. =E4=F6= =E8=F8=F4=E5 =E2=ED =E0=FA=ED =EC=F7=E4=E9=EC=FA MSN =E9=F9=F8=E0=EC. = http://www.msn.co.il From elguavas@users.sourceforge.net Sun Aug 4 03:10:05 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 04 Aug 2002 12:10:05 +1000 Subject: [Idle-dev] Re: IDLE UI Suggestion In-Reply-To: References: Message-ID: <1028427005.1631.18.camel@oberon> On Sun, 2002-08-04 at 00:57, unknown man wrote: > While idle may be part of Python, IDLEfork is the experimental IDLE > development team. Being as such submitting an idea to the IDLEfork > team is the best chance that the feature will end up in IDLE. Actually a lot of the changes that end up in production idle seem to come from patches submitted directly to python's (and thus idle's) own sourceforge tracker; and I then end up applying them 'back' to idlefork by tracking changes to python/idle cvs. This was the case for instance with the menu changes for the shell window that I mentioned already applying. So far only one or two minor bugfixes and no major features have ever made it the other way, from idlefork into idle. > BTW The > letters BDFL stand for 'Benevolent Dictator For Life' (meaning Guido > van Rossum). That abbreviation is one of the more common ways for > Python developers to refer to 'Guido van Rossum' (It is shorter, > easier to remember, and faster to type.) Ah, of course; while being perfectly aware of Guido being our BDFL, I've only ever used the long version of the phrase myself. I guess I've just always skipped over BDFL when I've seen it in emails before because it seemed to be just another BUATA (Boring Unnecessary And Trite Acronym) clogging up the airwaves... ;^) Actually I think GvR is surely the quickest and clearest way to refer to Guido, but then WTHWIK (What The Hell Would I Know). > As for the Tk icon I do hope > that they make the icon customizable. I could always use a resource > editor to change the icon (that works for windows computers, I have no > clue about any other system but those don't have the ugly icon problem > anyway) Me too. I think it looks very ugly and unprofessional not only in idle but also in all the other tkinter (and other Tk ui) apps ever run on windows too. Cheers, Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From elguavas@python.net Sun Aug 4 03:28:12 2002 From: elguavas@python.net (Stephen M. Gava) Date: 04 Aug 2002 12:28:12 +1000 Subject: [Idle-dev] Re: IDLE UI Suggestion In-Reply-To: <200208031441.g73Efe824675@pcp02138704pcs.reston01.va.comcast.net> References: <1028355107.528.31.camel@oberon> <200208031441.g73Efe824675@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <1028428093.1631.25.camel@oberon> Guido van Rossum wrote: > > > I have ranked them using a one star (*) to > > > five star (*****) System. I hope you can quickly change #1 and have > > > the BDFL approve it > > > > Sorry I don't know what BDFL is. > > "Benevolent Dictator For Life" == me. :-) Hmm of course; HISOM (How Incredibly Stupid Of Me)... ;^) -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From elguavas@users.sourceforge.net Mon Aug 5 02:34:43 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 05 Aug 2002 11:34:43 +1000 Subject: [Idle-dev] Re: IDLE UI Suggestion In-Reply-To: References: Message-ID: <1028511284.547.39.camel@oberon> On Mon, 2002-08-05 at 04:44, unknown man wrote: > >Actually a lot of the changes that end up in production idle seem to > >come from patches submitted directly to python's (and thus idle's) own > >sourceforge tracker; and I then end up applying them 'back' to idlefork > >by tracking changes to python/idle cvs. This was the case for instance > >with the menu changes for the shell window that I mentioned already > >applying. So far only one or two minor bugfixes and no major features > >have ever made it the other way, from idlefork into idle. > If that is the case than what is the point of idlefork? it seams a bit > silly to have an experimental slightly unstable version of the > software that is supposed to be used to add and test new features to > the original program if very few of the changes ever become part of > the original. Hmm, I suggest you read the information on the idlefork site about the history of the project, I don't really have the time to repeat it all here. I guess I should have added 'so far' to the above. The short version is that idlefork _is_ the official experimental version of idle; but the two first major new features being developed in idlefork (new configuration system, new separate process execution [rpc] model for code run and debugged from idle) have not yet been completed and stabilized to the point where they can be moved into stable idle. We are heading for a series of alpha, then beta testing releases for those major new features in the near future, and once they are stable in idlefork Guido has indicated he is keen to move them into stable python idle asap. The point of my answer above was to let you know that minor changes and bugfixes to idle (like the shell window menu ones) are more readily resolved in a timely manner by submitting them directly to idle/python. Major new features and restructuring of idle are the province of idlefork. These changes are happening in a fork so that production idle is never left in an unstable state as idlefork is much of the time. > > If I were a better Python programmer (I'm fairly new at Python) I would > download the latest Python release to have the latest IDLE. Then I > would download idle fork. I would then move the better idlefork > features over to Idle. Then at last I would have the best version of > idle/idlefork (perhaps I would call it IDLEspoon? :-) ). You would end up with idlefork. Idlefork is equivalent to the latest python/idle from cvs plus all the major new idlefork features in development. > If you are > wondering why I would not use idlefork directly is that it has been > noted that is slightly unstable (and i would not want program problems > messing up my program.) It is not slightly unstable at the moment, it is very unstable. ;^) It is development software and not recommended for day to day use except for the tarball releases we announce as being stable enough for that purpose. The last release in that condition was 0.8.1, available from the sourceforge site. Many people have used that one as their regular idle version, and the Vpython project adopted it as their standard idle. There have been many drastic changes to idlefork since then though, and for anyone interested we are currently maintaining a slightly more stable (though I would advise still unsuitable for full-on production use) cvs branch called DS_RPC_BRANCH, which has most of the new config stuff in it but none of the recent major RPC code execution changes. > What do you think the odds are that the Tk community would listen to > the suggestion of allowing the windows version of Tk to have a > customizable icon? I have no idea and I don't have the time to follow it up. Why don't you ask them? Some of the other questions you are asking have been answered many times before on idle-dev and other python mailing lists. You should try searching the list archives (there are links to them from the python site) for information. If you have more questions/suggestions please join idle-dev and float them there. That way the load of responding can be shared among the other developers and list readers as well. One piece of advice though, there is a strong preference for real names there. Regards, Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From kbk@users.sourceforge.net Mon Aug 5 04:52:12 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 04 Aug 2002 20:52:12 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.21,1.22 rpc.py,1.4,1.5 run.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv5390 Modified Files: PyShell.py rpc.py run.py Log Message: GvR provided solution to the socket rebinding timeout problem. M PyShell.py M rpc.py M run.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.21 retrieving revision 1.22 diff -C2 -r1.21 -r1.22 *** PyShell.py 26 Jul 2002 00:06:41 -0000 1.21 --- PyShell.py 5 Aug 2002 03:52:10 -0000 1.22 *************** *** 199,206 **** str(port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) ! # Idle starts listening for connection on localhost, retry since ! # Idle may be restarted before port is available for rebinding ! # XXX 25 July 2002 KBK Find out what is causing the delayed release! ! for i in range(12): time.sleep(i) try: --- 199,204 ---- str(port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) ! # Idle starts listening for connection on localhost ! for i in range(6): time.sleep(i) try: *************** *** 208,212 **** break except socket.error, err: ! if i < 5: print>>sys.__stderr__, ". ", else: --- 206,210 ---- break except socket.error, err: ! if i < 3: print>>sys.__stderr__, ". ", else: Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** rpc.py 26 Jul 2002 00:06:41 -0000 1.4 --- rpc.py 5 Aug 2002 03:52:10 -0000 1.5 *************** *** 404,407 **** --- 404,408 ---- def __init__(self, address, family=socket.AF_INET, type=socket.SOCK_STREAM): self.sock = socket.socket(family, type) + self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.sock.bind(address) self.sock.listen(1) Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** run.py 28 Jul 2002 03:35:31 -0000 1.5 --- run.py 5 Aug 2002 03:52:10 -0000 1.6 *************** *** 27,31 **** sys.argv[:] = [""] addr = ("localhost", port) ! for i in range(12): time.sleep(i) try: --- 27,31 ---- sys.argv[:] = [""] addr = ("localhost", port) ! for i in range(6): time.sleep(i) try: *************** *** 33,37 **** break except socket.error, err: ! if i < 5: print>>sys.__stderr__, ".. ", else: --- 33,37 ---- break except socket.error, err: ! if i < 3: print>>sys.__stderr__, ".. ", else: From elguavas@users.sourceforge.net Tue Aug 6 00:46:35 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 06 Aug 2002 09:46:35 +1000 Subject: [Idle-dev] Re: IDLE UI Suggestion (Thanks and Good Luck) In-Reply-To: References: Message-ID: <1028591196.538.7.camel@oberon> On Tue, 2002-08-06 at 01:30, unknown man wrote: > I will check out those lists. i would have already but I > have only seen the subscribe links. I will ahve to find the archive > links. anyway thanks for your time and good luck. The python.org pipermail archive for the general python list is at http://mail.python.org/pipermail/python-list/ the idle-dev one is at http://mail.python.org/pipermail/idle-dev/ there are also links to some python news group and mailing list archive search interfaces at http://www.python.org/search/search_news.html Ciao, Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From elguavas@users.sourceforge.net Tue Aug 6 01:42:10 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Mon, 05 Aug 2002 17:42:10 -0700 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.23.2.3,1.23.2.4 PyShell.py,1.13.2.2,1.13.2.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv25461 Modified Files: Tag: DS_RPC_BRANCH EditorWindow.py PyShell.py Log Message: general cleanup: remove purposeless and incorrect 'binding comments' Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.23.2.3 retrieving revision 1.23.2.4 diff -C2 -r1.23.2.3 -r1.23.2.4 *** EditorWindow.py 24 Jul 2002 23:44:02 -0000 1.23.2.3 --- EditorWindow.py 6 Aug 2002 00:42:08 -0000 1.23.2.4 *************** *** 1,7 **** - # changes by dscherer@cmu.edu - # - created format and run menus - # - added silly advice dialog (apologies to Douglas Adams) - # - made Python Documentation work on Windows (requires win32api to - # do a ShellExecute(); other ways of starting a web browser are awkward) import sys --- 1,2 ---- *************** *** 27,86 **** # The default tab setting for a Text widget, in average-width characters. TK_TABWIDTH_DEFAULT = 8 - - # File menu - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - - #$ event <> - - #$ unix - #$ unix - #$ win - - # Edit menu - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - # Help menu - - #$ event <> - #$ win - #$ unix - - #$ event <> - - # Events without menu entries - - #$ event <> - #$ win - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ unix class EditorWindow: --- 22,25 ---- Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.13.2.2 retrieving revision 1.13.2.3 diff -C2 -r1.13.2.2 -r1.13.2.3 *** PyShell.py 24 Jul 2002 23:44:02 -0000 1.13.2.2 --- PyShell.py 6 Aug 2002 00:42:08 -0000 1.13.2.3 *************** *** 60,97 **** linecache.checkcache = linecache_checkcache - - # Note: <> event is defined in AutoIndent.py - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ win - #$ unix - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - - #$ event <> - - class PyShellEditorWindow(EditorWindow): --- 60,63 ---- From elguavas@users.sourceforge.net Tue Aug 6 01:45:54 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Mon, 05 Aug 2002 17:45:54 -0700 Subject: [Idle-dev] CVS: idle eventparse.py,1.2,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv26475 Removed Files: Tag: DS_RPC_BRANCH eventparse.py Log Message: general cleanup: serves no purpose anymore, move to attic --- eventparse.py DELETED --- From elguavas@users.sourceforge.net Tue Aug 6 01:53:47 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Mon, 05 Aug 2002 17:53:47 -0700 Subject: [Idle-dev] CVS: idle FrameViewer.py,1.2,NONE MultiScrolledLists.py,1.3,NONE Remote.py,1.2,NONE RemoteInterp.py,1.3,NONE Separator.py,1.3,NONE loader.py,1.2,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv28234 Removed Files: Tag: DS_RPC_BRANCH FrameViewer.py MultiScrolledLists.py Remote.py RemoteInterp.py Separator.py loader.py Log Message: general cleanup: retired, currently unused, and not to be used modules; move to attic --- FrameViewer.py DELETED --- --- MultiScrolledLists.py DELETED --- --- Remote.py DELETED --- --- RemoteInterp.py DELETED --- --- Separator.py DELETED --- --- loader.py DELETED --- From elguavas@users.sourceforge.net Tue Aug 6 02:00:25 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Mon, 05 Aug 2002 18:00:25 -0700 Subject: [Idle-dev] CVS: idle ToolTip.py,1.3,1.3.2.1 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30108 Modified Files: Tag: DS_RPC_BRANCH ToolTip.py Log Message: general cleanup: indicate why we'll keep this here for now Index: ToolTip.py =================================================================== RCS file: /cvsroot/idlefork/idle/ToolTip.py,v retrieving revision 1.3 retrieving revision 1.3.2.1 diff -C2 -r1.3 -r1.3.2.1 *** ToolTip.py 14 Jul 2001 01:14:09 -0000 1.3 --- ToolTip.py 6 Aug 2002 01:00:22 -0000 1.3.2.1 *************** *** 1,2 **** --- 1,5 ---- + # general purpose 'tooltip' routines - currently unused in idlefork + # (although the 'calltips' extension is partly based on this code) + # may be useful for some purposes in (or almost in ;) the current project scope # Ideas gleaned from PySol From elguavas@users.sourceforge.net Wed Aug 7 02:46:13 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 06 Aug 2002 18:46:13 -0700 Subject: [Idle-dev] CVS: idle ParenMatch.py,1.4,1.4.2.1 EditorWindow.py,1.23.2.4,1.23.2.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv11997 Modified Files: Tag: DS_RPC_BRANCH ParenMatch.py EditorWindow.py Log Message: remove last dependencies on and references to the old config backend module IdleConf.py Index: ParenMatch.py =================================================================== RCS file: /cvsroot/idlefork/idle/ParenMatch.py,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -C2 -r1.4 -r1.4.2.1 *** ParenMatch.py 19 Jan 2002 10:41:51 -0000 1.4 --- ParenMatch.py 7 Aug 2002 01:46:10 -0000 1.4.2.1 *************** *** 15,19 **** import PyParse from AutoIndent import AutoIndent, index2line ! from IdleConf import idleconf class ParenMatch: --- 15,19 ---- import PyParse from AutoIndent import AutoIndent, index2line ! from configHandler import idleConf class ParenMatch: *************** *** 45,54 **** """ menudefs = [] ! iconf = idleconf.getsection('ParenMatch') ! STYLE = iconf.getdef('style', 'default') ! FLASH_DELAY = iconf.getint('flash-delay') ! HILITE_CONFIG = iconf.getcolor('hilite') ! BELL = iconf.getboolean('bell') ! del iconf def __init__(self, editwin): --- 45,55 ---- """ menudefs = [] ! STYLE = idleConf.GetOption('extensions','ParenMatch','style', ! default='expression') ! FLASH_DELAY = idleConf.GetOption('extensions','ParenMatch','flash-delay', ! type='int',default=500) ! HILITE_CONFIG = idleConf.GetHighlight(idleConf.CurrentTheme(),'hilite') ! BELL = idleConf.GetOption('extensions','ParenMatch','bell', ! type='bool',default=1) def __init__(self, editwin): Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.23.2.4 retrieving revision 1.23.2.5 diff -C2 -r1.23.2.4 -r1.23.2.5 *** EditorWindow.py 6 Aug 2002 00:42:08 -0000 1.23.2.4 --- EditorWindow.py 7 Aug 2002 01:46:10 -0000 1.23.2.5 *************** *** 16,20 **** import ReplaceDialog import PyParse - #from IdleConf import idleconf from configHandler import idleConf import aboutDialog, textView, configDialog --- 16,19 ---- From elguavas@users.sourceforge.net Wed Aug 7 02:47:41 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 06 Aug 2002 18:47:41 -0700 Subject: [Idle-dev] CVS: idle IdleConf.py,1.4,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv13160 Removed Files: Tag: DS_RPC_BRANCH IdleConf.py Log Message: retire to the attic --- IdleConf.py DELETED --- From elguavas@users.sourceforge.net Wed Aug 7 02:58:10 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 06 Aug 2002 18:58:10 -0700 Subject: [Idle-dev] CVS: idle Bindings.py,1.9.2.1,1.9.2.2 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv18794 Modified Files: Tag: DS_RPC_BRANCH Bindings.py Log Message: general cleanup and remove last references to old config backend module keydefs.py Index: Bindings.py =================================================================== RCS file: /cvsroot/idlefork/idle/Bindings.py,v retrieving revision 1.9.2.1 retrieving revision 1.9.2.2 diff -C2 -r1.9.2.1 -r1.9.2.2 *** Bindings.py 22 Jul 2002 02:26:04 -0000 1.9.2.1 --- Bindings.py 7 Aug 2002 01:58:08 -0000 1.9.2.2 *************** *** 6,19 **** # Debug menu here, which is only present in the PythonShell window. - # changes by dscherer@cmu.edu: - # - Python shell moved to 'Run' menu - # - "Help" renamed to "IDLE Help" to distinguish from Python help. - # The distinction between the environment and the language is dim - # or nonexistent in a novice's mind. - # - Silly advice added - import sys import string - #from keydefs import * from configHandler import idleConf --- 6,11 ---- From elguavas@users.sourceforge.net Wed Aug 7 03:01:22 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 06 Aug 2002 19:01:22 -0700 Subject: [Idle-dev] CVS: idle keydefs.py,1.3,NONE config-unix.txt,1.2,NONE config-win.txt,1.2,NONE config.txt,1.4,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv20503 Removed Files: Tag: DS_RPC_BRANCH keydefs.py config-unix.txt config-win.txt config.txt Log Message: retire more old config backend files to attic --- keydefs.py DELETED --- --- config-unix.txt DELETED --- --- config-win.txt DELETED --- --- config.txt DELETED --- From elguavas@users.sourceforge.net Wed Aug 7 03:27:59 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 06 Aug 2002 19:27:59 -0700 Subject: [Idle-dev] CVS: idle CallTips.py,1.4,1.4.2.1 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv32661 Modified Files: Tag: DS_RPC_BRANCH CallTips.py Log Message: tracking python/idle cvs changes Index: CallTips.py =================================================================== RCS file: /cvsroot/idlefork/idle/CallTips.py,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -C2 -r1.4 -r1.4.2.1 *** CallTips.py 19 Jan 2002 10:39:47 -0000 1.4 --- CallTips.py 7 Aug 2002 02:27:57 -0000 1.4.2.1 *************** *** 64,68 **** def get_object_at_cursor(self, ! wordchars="._" + string.uppercase + string.lowercase + string.digits): # XXX - This needs to be moved to a better place # so the "." attribute lookup code can also use it. --- 64,71 ---- def get_object_at_cursor(self, ! wordchars="._" + string.ascii_letters + string.digits): ! # Usage of ascii_letters is necessary to avoid UnicodeErrors ! # if chars contains non-ASCII. ! # XXX - This needs to be moved to a better place # so the "." attribute lookup code can also use it. From elguavas@python.net Wed Aug 7 03:51:07 2002 From: elguavas@python.net (Stephen M. Gava) Date: 07 Aug 2002 12:51:07 +1000 Subject: [Idle-dev] merge DS_RPC_BRANCH back to main? Message-ID: <1028688668.13195.13.camel@oberon> Kurt, I was wondering whether it's time to do a merge of the branch I've been working on back to the trunk? Also, I'm keen to go back to working on (and therefore being able to readily test, by default) the trunk myself. How much longer do you think we others need to keep our commits on DS_RPC_BRANCH? I think if we are going to head toward some alpha/testing releases we need to get everyone back on the trunk, also, there are some changes I need to make to track a recent major python/idle patch that overlap with some that were made on MAIN a while back but not on DS_RPC_BRANCH, and I'd like to avoid making the first lot of changes on the branch I've been working on again as well as applying the new patches. So, what do you think, has the SPE/RPC stuff settled down enough now that other development can continue on the trunk as well now? Guido, do you have an opinion on this as well? Cheers, Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From guido@python.org Wed Aug 7 04:06:21 2002 From: guido@python.org (Guido van Rossum) Date: Tue, 06 Aug 2002 23:06:21 -0400 Subject: [Idle-dev] Re: merge DS_RPC_BRANCH back to main? In-Reply-To: Your message of "Wed, 07 Aug 2002 12:51:07 +1000." <1028688668.13195.13.camel@oberon> References: <1028688668.13195.13.camel@oberon> Message-ID: <200208070306.g7736Ln28360@pcp02138704pcs.reston01.va.comcast.net> > So, what do you think, has the SPE/RPC stuff settled down enough now > that other development can continue on the trunk as well now? Guido, do > you have an opinion on this as well? Not really, I haven't been following this. I thought that Kurt was already working on the trunk??? --Guido van Rossum (home page: http://www.python.org/~guido/) From elguavas@python.net Wed Aug 7 04:17:46 2002 From: elguavas@python.net (Stephen M. Gava) Date: 07 Aug 2002 13:17:46 +1000 Subject: [Idle-dev] Re: merge DS_RPC_BRANCH back to main? In-Reply-To: <200208070306.g7736Ln28360@pcp02138704pcs.reston01.va.comcast.net> References: <1028688668.13195.13.camel@oberon> <200208070306.g7736Ln28360@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <1028690267.13407.5.camel@oberon> > > So, what do you think, has the SPE/RPC stuff settled down enough now > > that other development can continue on the trunk as well now? Guido, do > > you have an opinion on this as well? > > Not really, I haven't been following this. Ok. > I thought that Kurt was > already working on the trunk??? Yeah, he is, but a while back he and you decided that everyone else should continue to work on DS_RPC_BRANCH while the first cuts of the spe/rpc stuff were made on the trunk, because those changes were feared likely to cause major breakage. I'm hoping things are stable enough on the trunk now that we can merge DS_RPC_BRANCH back and all continue to work there now. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From kbk@shore.net Wed Aug 7 05:22:03 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: Wed, 07 Aug 2002 00:22:03 -0400 Subject: [Idle-dev] Re: merge DS_RPC_BRANCH back to main? References: <1028688668.13195.13.camel@oberon> <200208070306.g7736Ln28360@pcp02138704pcs.reston01.va.comcast.net> <1028690267.13407.5.camel@oberon> Message-ID: <3D50A06B.ACC68972@shore.net> "Stephen M. Gava" wrote: > > > > So, what do you think, has the SPE/RPC stuff settled down enough now > > > that other development can continue on the trunk as well now? Guido, do > > > you have an opinion on this as well? > > > > Not really, I haven't been following this. > > Ok. > > > I thought that Kurt was > > already working on the trunk??? > > Yeah, he is, but a while back he and you decided that everyone else > should continue to work on DS_RPC_BRANCH while the first cuts of the > spe/rpc stuff were made on the trunk, because those changes were feared > likely to cause major breakage. I'm hoping things are stable enough on > the trunk now that we can merge DS_RPC_BRANCH back and all continue to > work there now. There is one major task remaining. Just clearing/massaging the global environment and sys is not an adequate substitute for simply restarting the Python execution server on Run/F5. There are too many possible side effects, especially if the user wants to edit the modules used by the execution server. I'm currently working on the code to do the restart. This may involve some significant changes and it may be best to hold off for a bit and let me complete that. As far as stability goes, MAIN actually seems pretty solid, though it might become unstable for awhile after I introduce the restart code. I'm hoping not, we'll see. It would be good to get more eyes on it. I was thinking that since it's been a year since there was a release of the Visual Python version of Idlefork, that they would appreciate another release of the DS_RPC_BRANCH which contains all the work you have done to date and the merges of Python Idle bugfixes. So the cleanup work you are doing is quite appropriate for a "final" release. The new merge from Python Idle you mentioned (PEP263??), would that be useful to the VP branch? Once we merge to MAIN, I suppose there would only be critical bug fixes on the DS_RPC_BRANCH. Then we need to convince Scherer/Sherwood et. al. (via config options?) that the MAIN line of development is a good way to continue for their purposes. Regards, KBK From elguavas@python.net Wed Aug 7 06:59:08 2002 From: elguavas@python.net (Stephen M. Gava) Date: 07 Aug 2002 15:59:08 +1000 Subject: [Idle-dev] Re: merge DS_RPC_BRANCH back to main? In-Reply-To: <3D50A06B.ACC68972@shore.net> References: <1028688668.13195.13.camel@oberon> <200208070306.g7736Ln28360@pcp02138704pcs.reston01.va.comcast.net> <1028690267.13407.5.camel@oberon> <3D50A06B.ACC68972@shore.net> Message-ID: <1028699952.13664.84.camel@oberon> > It would be good to get more eyes on it. Continuing all work on main now would accomplish this. > I was thinking that since it's been a year since there was a release of the > Visual Python version of Idlefork, that they would appreciate another release > of the DS_RPC_BRANCH which contains all the work you have done to date and the > merges of Python Idle bugfixes. Hmm, I think there is a fundanmental misunderstanding here. There is no vpython version of idlefork, and there hasn't been since the 0.8.1 release. I'm not talking semantics here, I mean that any pretense of a semi-stable relationship to that earlier codebase was dropped long ago. That was the last idlefork with no drastic changes from previous still-relatively-close-to-vpython versions. Since then there have been _major_ changes to many areas of idlefork that so far are untested except for use by developers and a small number of cvs checkout users. The entire configuration backend has been rewritten and replaced as the underpinning for the entire new configuration frontend, for instance. I expect there are minor (but possibly major, hopefully not) breakages all over the place as a result of all this new code. > So the cleanup work you are doing is quite > appropriate for a "final" release. My intention is that I am tidying up (and also still developing) for a (hopefully reasonably near future) series of alpha/testing releases, which will include the new rpc stuff and the new config engine. > The new merge from Python Idle you > mentioned (PEP263??), would that be useful to the VP branch? All these merges need to be in main so everyone can work there and test by default. I don't really think that with a developer base of our size (really only two who are very active) we can indefinitely maintain two development streams. > Once we merge to MAIN, I suppose there would only be critical bug fixes on the > DS_RPC_BRANCH. Then we need to convince Scherer/Sherwood et. al. (via config > options?) that the MAIN line of development is a good way to continue for their > purposes. The vpython folk are in the same boat as everyone else, when there is a new idlefork release that is at least beta quality they will be able to consider whether to adopt it or not. The intention is clearly that idlefork will eventually become python/idle and then python/idle will be suitable for all idle users including vpython. The idea is to end the forking of production idle, and the need for any forking, not to keep it going. We agreed on the DS_RPC_BRANCH as a place for non new-rpc development to move to while (if?) things were drastically broken by moving in the new rpc stuff. My impression is that it's moved in now and into ongoing development (correct me if I'm wrong though). I don't want to keep our tiny development team (of mostly two) spread indefinitely over two branches. We need to both be focusing on one version now (or asap at least) so it can all come together for some test releases. Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From tarlano@yahoo.com Thu Aug 15 19:16:04 2002 From: tarlano@yahoo.com (tarlano@yahoo.com) Date: Thu, 15 Aug 2002 20:16:04 +0200 Subject: [Idle-dev] setting pythonhome and pythonstartup Message-ID: <3D5BEFE4.1070802@yahoo.com> Currently on my winXp system, I have both pythonhome and python startup as enviroment variables that work just find with the python interact shell, but for some reason are not read in by IDLE? Can someone tell me what I need to do.. Thanks, Anthony From basherwo@unity.ncsu.edu Fri Aug 16 01:51:34 2002 From: basherwo@unity.ncsu.edu (Bruce Sherwood) Date: Thu, 15 Aug 2002 20:51:34 -0400 Subject: [Idle-dev] setting pythonhome and pythonstartup References: <3D5BEFE4.1070802@yahoo.com> Message-ID: <001101c244bf$1219fad0$6701a8c0@hyperon> Can you say what problem you're trying to solve? What is it that you want to do? Bruce Sherwood ----- Original Message ----- From: To: Sent: Thursday, August 15, 2002 2:16 PM Subject: [Idle-dev] setting pythonhome and pythonstartup > Currently on my winXp system, I have both pythonhome and python startup > as enviroment variables that work just find with the python interact > shell, but for some reason are not read in by IDLE? Can someone tell me > what I need to do.. > > Thanks, > > Anthony From glingl@aon.at Tue Aug 20 00:04:38 2002 From: glingl@aon.at (Gregor Lingl) Date: Tue, 20 Aug 2002 01:04:38 +0200 Subject: [Idle-dev] German Umlaut and raw_input! References: <1028688668.13195.13.camel@oberon> <200208070306.g7736Ln28360@pcp02138704pcs.reston01.va.comcast.net> <1028690267.13407.5.camel@oberon> <3D50A06B.ACC68972@shore.net> <1028699952.13664.84.camel@oberon> Message-ID: <3D617986.4000904@aon.at> Hi, idle-dev people! Some month ago I copied sitecustomize.py with appropriate locale-setting to C:\Python22\Lib thanks to an advice of someone on this list. This worked well until today I made the observation, that raw_input doesn't work correctly: >>> a = raw_input("Hä? ") Hä? Tschüs Traceback (most recent call last): File "", line 1, in ? a = raw_input("Hä? ") TypeError: object.readline() returned non-string >>> Consequently I cannot execute programs with raw_input from IDLE, if the expected answers may contain "Umlaute". Those same programs, however, can be executed from the commandline. And also the interactive Python interpreter can execute raw_input statements even when Umlaute are input. So I think, this must be a problem of IDLE. I must confess, I do not understand the error message. Hope this can be corrected somehow. Thanks Gregor Lingl From kbk@users.sourceforge.net Sun Aug 25 00:57:20 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 24 Aug 2002 16:57:20 -0700 Subject: [Idle-dev] CVS: idle rpc.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv12569 Modified Files: rpc.py Log Message: Improve exception handling across rpc interface Modified Files: rpc.py Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** rpc.py 5 Aug 2002 03:52:10 -0000 1.5 --- rpc.py 24 Aug 2002 23:57:17 -0000 1.6 *************** *** 209,213 **** mod, name, args, tb = what self.traceback = tb ! if mod: try: __import__(mod) --- 209,213 ---- mod, name, args, tb = what self.traceback = tb ! if mod: # not string exception try: __import__(mod) *************** *** 221,225 **** --- 221,228 ---- pass else: + # instantiate a built-in exception object and raise it raise getattr(__import__(mod), name)(*args) + name = mod + "." + name + # do the best we can: raise name, args if how == "ERROR": From kbk@users.sourceforge.net Sun Aug 25 15:08:09 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 25 Aug 2002 07:08:09 -0700 Subject: [Idle-dev] CVS: idle ScriptBinding.py,1.7,1.8 rpc.py,1.6,1.7 run.py,1.6,1.7 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv25166 Modified Files: ScriptBinding.py rpc.py run.py Log Message: 1. Revert subprocess environment clearing, will restart subprocess instead. 2. Preserve the Idle client's listening socket for reuse with the fresh subprocess. 3. Remove some unused rpc code, comment out additional unused code. Modified Files: ScriptBinding.py rpc.py run.py Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** ScriptBinding.py 28 Jul 2002 03:35:31 -0000 1.7 --- ScriptBinding.py 25 Aug 2002 14:08:07 -0000 1.8 *************** *** 148,153 **** shell = flist.open_shell() interp = shell.interp - # clear the subprocess environment before every Run/F5 invocation - interp.rpcclt.remotecall("exec", "clear_the_environment", (), {}) # XXX Too often this discards arguments the user just set... interp.runcommand("""if 1: --- 148,151 ---- Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** rpc.py 24 Aug 2002 23:57:17 -0000 1.6 --- rpc.py 25 Aug 2002 14:08:07 -0000 1.7 *************** *** 50,62 **** return unpickle_code, (ms,) ! def unpickle_function(ms): ! return ms ! ! def pickle_function(fn): ! assert isinstance(fn, type.FunctionType) ! return `fn` copy_reg.pickle(types.CodeType, pickle_code, unpickle_code) ! copy_reg.pickle(types.FunctionType, pickle_function, unpickle_function) BUFSIZE = 8*1024 --- 50,63 ---- return unpickle_code, (ms,) ! # XXX KBK 24Aug02 function pickling capability not used in Idle ! # def unpickle_function(ms): ! # return ms ! ! # def pickle_function(fn): ! # assert isinstance(fn, type.FunctionType) ! # return `fn` copy_reg.pickle(types.CodeType, pickle_code, unpickle_code) ! # copy_reg.pickle(types.FunctionType, pickle_function, unpickle_function) BUFSIZE = 8*1024 *************** *** 67,72 **** if handlerclass is None: handlerclass = RPCHandler - # XXX KBK 25Jun02 Not used in Idlefork. - # self.objtable = objecttable SocketServer.TCPServer.__init__(self, addr, handlerclass) --- 68,71 ---- *************** *** 87,102 **** "Override TCPServer method, return already connected socket" return self.socket, self.server_address - - - # XXX The following two methods are not currently used in Idlefork. - # def register(self, oid, object): - # self.objtable[oid] = object - - # def unregister(self, oid): - # try: - # del self.objtable[oid] - # except KeyError: - # pass - objecttable = {} --- 86,89 ---- *************** *** 406,419 **** def __init__(self, address, family=socket.AF_INET, type=socket.SOCK_STREAM): ! self.sock = socket.socket(family, type) ! self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) ! self.sock.bind(address) ! self.sock.listen(1) def accept(self): ! newsock, address = self.sock.accept() if address[0] == '127.0.0.1': print>>sys.__stderr__, "Idle accepted connection from ", address ! SocketIO.__init__(self, newsock) else: print>>sys.__stderr__, "Invalid host: ", address --- 393,407 ---- def __init__(self, address, family=socket.AF_INET, type=socket.SOCK_STREAM): ! self.listening_sock = socket.socket(family, type) ! self.listening_sock.setsockopt(socket.SOL_SOCKET, ! socket.SO_REUSEADDR, 1) ! self.listening_sock.bind(address) ! self.listening_sock.listen(1) def accept(self): ! working_sock, address = self.listening_sock.accept() if address[0] == '127.0.0.1': print>>sys.__stderr__, "Idle accepted connection from ", address ! SocketIO.__init__(self, working_sock) else: print>>sys.__stderr__, "Invalid host: ", address Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** run.py 5 Aug 2002 03:52:10 -0000 1.6 --- run.py 25 Aug 2002 14:08:07 -0000 1.7 *************** *** 2,6 **** import time import socket - import __main__ import rpc --- 2,5 ---- *************** *** 57,72 **** def __init__(self, rpchandler): self.rpchandler = rpchandler ! self.base_env_keys = __main__.__dict__.keys() def runcode(self, code): ! exec code in __main__.__dict__ ! ! def clear_the_environment(self): ! global __main__ ! env = __main__.__dict__ ! for key in env.keys(): ! if key not in self.base_env_keys: ! del env[key] ! env['__doc__'] = None def start_the_debugger(self, gui_adap_oid): --- 56,64 ---- def __init__(self, rpchandler): self.rpchandler = rpchandler ! import __main__ ! self.locals = __main__.__dict__ def runcode(self, code): ! exec code in self.locals def start_the_debugger(self, gui_adap_oid):