From noreply at sourceforge.net Tue Dec 2 13:07:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 13:07:49 2003 Subject: [Idle-dev] [ idlefork-Bugs-629985 ] Slow output Message-ID: Bugs item #629985, was opened at 2002-10-28 12:28 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=629985&group_id=9579 Category: None Group: None Status: Closed Resolution: Fixed Priority: 4 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Kurt B. Kaiser (kbk) Summary: Slow output Initial Comment: When a program writes many small amounts of text to sys.stdout, the RPC package really seems to slow things down. Perhaps the RPC mechanism can be extended with a special case for "no-return" method calls, where the client doesn't wait for a response and the server doesn't send one. (This should only be done for functions that aren't expected to return a value or raise an exception, of course.) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-12-02 13:07 Message: Logged In: YES user_id=149084 Quite right! The notes were incorrect and pernicious pasting took care of the rest. It's select.select() and wait=0.0. ModifiedInterpreter.poll_subprocess() wasn't setting the wait parameter so it was silently defaulting to 0.0 which caused pollresponse() to return immediately if there was no data. It then rescheduled itself. This was causing a 100% slowdown relative to just waiting for 50 ms in rpc's SocketIO.pollpacket(). There was also a stutter at the beginning of the output which made it look even worse. I never did figure out what was causing the stutter but it went away when I made the change. (This comment relates to the synchronous comm link.) The async link was a different case, it was blocking instead of polling in pollpacket(). At this point IDLE1.0 is 70% slower than IDLE0.8 when outputting sequences of " 1". This is some kind of worst case. It's still pretty responsive, and this particular problem isn't an issue in most cases, the limiting factor is the Tk text scrolling. I'll bum it some more some day. Thanks for the correction! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-30 16:51 Message: Logged In: YES user_id=6380 I don't see any signal calls in the rpc code. Maybe you meant select.select? Also, wait=None should cause select() to wait forever (until I/O is possible), not return immediately. But yes, it does look like it was being invoked with wait=None from asyncreturn(), and that was switched to 0.05 on May 8th in rpc.py rev 1.23. (The CVS comment also mistakenly talks about signal instead of select. :-) In any case, thanks for the changes, the response time really *is* much better now. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-30 15:17 Message: Logged In: YES user_id=149084 Retrospective: This was greatly improved in May 2003 by tuning the signal() parameters. From my notes at the time, for future reference: "Problem was being caused by rpc.SocketIO.ioready() using a wait=None. This causes signal.signal to return immediately forcing re-schedule of PyShell.ModifiedInterpreter.poll_subprocess(), I think. Setting these wait()s to 50 ms helped a lot - got about 100% improvement from worst case." ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 14:18 Message: Logged In: YES user_id=6380 I think this has been hashed to death; there are some mysteries, but it's no big deal any more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=629985&group_id=9579 From noreply at sourceforge.net Thu Dec 4 13:27:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 4 13:27:39 2003 Subject: [Idle-dev] [ idlefork-Bugs-780346 ] Unable to see Recent Files submenu when "File" menu teared Message-ID: Bugs item #780346, was opened at 2003-07-30 11:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=780346&group_id=9579 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Recent Files submenu when "File" menu teared Initial Comment: Using IDLE version 1.0, if you 'tear off' the File menu you are unable to see the Recent Files submenu. Reproduce: 1. Tear off the File Menu, this is done by clicking the dotted line. 2. On the teared off menu, highlight "Recent Files" with the mouse. Observe you are unable to see the sub menu. This has been reproduced/seen on Windows 2000/XP. /Gus ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-12-04 13:27 Message: Logged In: YES user_id=149084 If not torn off, Recent Files window appears on all desktops (OpenBSD/Ion, Linux/Enlightenment) and if torn off, it doesn't have that problem but the window has no name. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-09-05 16:59 Message: Logged In: YES user_id=149084 On XP: If you tear off the menu and highlight Recent Files, the submenu doesn't drop down, just as OP claims. But if you then click on Recent Files, the submenu appears, and can be torn off. A more serious issue is that if you click again, the submenu disappears (as expected) but you can't open it again without clicking somewhere else on the torn-off menu first. On Linux the drop down doesn't appear on mouse- over, you have to click. And clicking again on Recent Files doesn't close the submenu, you have to click elsewhere or hit esc twice, closing both the submenu and the Files menu. If the Files menu is torn off, esc does nothing. I claim that these are (minor) Tk issues, possibly tkinter. Lowering priority. Someone needs to do a cutdown to resolve where the problem lies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=780346&group_id=9579 From webworldl at yahoo.com Wed Dec 17 17:22:23 2003 From: webworldl at yahoo.com (Luke Bradley) Date: Thu Dec 18 13:13:56 2003 Subject: [Idle-dev] modifying color rules Message-ID: <20031217222223.85980.qmail@web11101.mail.yahoo.com> Hello! I'm interested in changing the coloring rules in idle for a different type of file, one that includes python embedded in HTML. This file type is my own creation and has a different suffix. I was wondering if any of the developers being familiar with the code structure know of a quick way to apply a different set of coloring rules for a different type of file, or a good place to jump into the code for this type of thing. Thanks so much for replies Luke Bradley --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20031217/d862b6cb/attachment.html From kbk at users.sourceforge.net Thu Dec 18 20:00:01 2003 From: kbk at users.sourceforge.net (Kurt B. Kaiser) Date: Thu Dec 18 20:00:09 2003 Subject: [Idle-dev] CVS: website index.html,1.3,1.4 mission.html,1.1,1.2 Message-ID: Update of /cvsroot/idlefork/website In directory sc8-pr-cvs1:/tmp/cvs-serv23847 Modified Files: index.html mission.html Log Message: Updated web pages to reflect completion of project. M index.html M mission.html Index: index.html =================================================================== RCS file: /cvsroot/idlefork/website/index.html,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** index.html 11 Sep 2002 01:09:07 -0000 1.3 --- index.html 19 Dec 2003 00:59:59 -0000 1.4 *************** *** 21,39 **** The  IDLEfork  Project " just like IDLE, only crunchy " - -
-      - Home -      - News -      - Mission Statement -      - Current Tasks -      - Developer Info -     
- --- 21,27 ---- The  IDLEfork  Project " just like IDLE, only crunchy " +

+   *************** *** 55,66 **** ! Bug Reports ! ! ! Submit Patches ! - Browse CVS -   --- 43,48 ---- ! Mission   *************** *** 75,81 **** Archives - - Post -   --- 57,60 ---- *************** *** 124,155 ****
!

Introduction

! The IDLEfork project is an official experimental development fork of Python's ! small, light, 'bundled' integrated development environment, IDLE. Changes ! to this version that are approved by Python's benevolent dictator ! for life (python's creator, Guido van Rossum) will go back into the stable distribution version.

! The IDLEfork project is hosted by SourceForge and its project page can be found at: http://sourceforge.net/projects/idlefork .

! Python is an open source, general purpose, object oriented computer programming language. Python's power, flexibility, clarity, ease of use and ease of maintenance sees it currently being used by a large and rapidly increasing number of individuals, and organisations large and small, commercial and non-commercial, around the world. It is in use for open and closed source projects ranging in scope from trivial to immensely complex. Python code is automatically byte-compiled to run efficiently in its interpreter, without change on a wide variety of platforms.


How To Contribute

! Everyone interested in IDLE is invited to contribute to the IDLEfork by ! means of discussion, bug reports and coding nifty patches. If you want to contribute code to IDLEfork regularly, you can become a developer by mailing the project coordinator, Kurt B. Kaiser. See the Developer Info page first.
 
Discussion

Discussion of development for IDLE is carried out on the ! idle-dev mailing list  ! <idle-dev@python.org> at the Python Language Website. ! Subscription information for idle-dev can be found at: ! http://www.python.org/mailman/listinfo/idle-dev. The archives of the idle-dev list can be perused at: http://mail.python.org/pipermail/idle-dev.

Bug Reports !

IDLEfork uses the Bug Tracking facility provided by SourceForge. It ! can be found at: ! http://sourceforge.net/bugs/?group_id=9579.

!

! Patches !

To submit patches, the Patch Manager at SourceForge is used. This can be found at: ! http://sourceforge.net/patch/?group_id=9579. !

  --- 103,177 ----
!

The IDLEfork project has been completed!

!

NOTE: Python 2.3 users should use IDLE, not IDLEfork!

!

! The IDLEfork project was an official experimental development fork of Python's ! small, light, 'bundled' integrated development environment, IDLE. !

! The objective was to develop a version of IDLE which had an execution ! environment which could be initialized prior to each run of user code. !

! The IDLEfork project was initiated by David Scherer, with some help from Peter ! Schneider-Kamp and Nicholas Riley. David wrote the first version of the RPC ! code and designed a fast turn-around environment for VPython. Guido van Rossum ! developed the RPC code and Remote Debugger currently integrated in IDLE. Bruce ! Sherwood contributed considerable time testing and suggesting improvements. !

! Besides David and Guido, the main developers who have been active on IDLEfork ! are Stephen M. Gava, who implemented the configuration GUI, the new ! configuration system, and the About dialog, and Kurt B. Kaiser, who completed ! the integration of the RPC and remote debugger, implemented the threaded ! subprocess, and made a number of usability enhancements. !

! Other contributors include Raymond Hettinger, Tony Lownds (Mac integration), ! Neal Norwitz (code check and clean-up), and Chui Tey (RPC integration, debugger ! integration and persistent breakpoints). !

! Scott David Daniels, Hernan Foffani, Christos Georgiou, Martin v. L?wis, ! Jason Orendorff, Noam Raphael, Josh Robb, Nigel Rowe, and Bruce Sherwood have ! submitted useful patches. Thanks, guys! !

! For additional details refer to NEWS.txt and Changelog. !

! On June 29, 2003 the IDLEfork code base (rev 0.9b1) was merged back into ! Python. Its location in the Python source tree was moved from .../Tools/idle ! to .../Lib/idlelib, and the IDLEfork project went into bugfix mode. !

!

Future Plans

! IDLEfork was targeted to Python 2.2 (>= 2.2.1). When it was merged into ! Python, the subprocess main thread interrupt code became part of Python's ! thread module and IDLE once more was coded in pure Python. However, that means ! that the version of IDLE in Python 2.3 will not work in Python 2.2. !

! To support Python 2.2 users, IDLEfork will be maintained in bugfix mode until ! the number of downloads shows that the users have moved on to Python 2.3. !

! It's also possible that beta versions of IDLE (for Python >= 2.3) may ! occasionally be posted on the IDLEfork download area. !


How To Contribute

! Everyone interested in the future development of IDLE is invited to contribute ! by means of discussion, bug reports and patches.
Discussion

Discussion of development for IDLE is carried out on the ! idle-dev mailing list ! at the Python Language Website. ! Subscription information for idle-dev can be found ! here. ! The archives of the idle-dev list can be perused here. !

Bug Reports !

IDLE uses the Python Bug Tracking facility provided by SourceForge. It ! can be found ! here. !

!

Patches !

The Python Patch Tracer can be found ! here.. !

!

  Index: mission.html =================================================================== RCS file: /cvsroot/idlefork/website/mission.html,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** mission.html 24 Jul 2001 12:33:20 -0000 1.1 --- mission.html 19 Dec 2003 00:59:59 -0000 1.2 *************** *** 21,39 **** The  IDLEfork  Project     --    Mission Statement - -

-      - Home -      - News -      - Mission Statement -      - Current Tasks -      - Developer Info -     
- --- 21,27 ---- The  IDLEfork  Project     --    Mission Statement +

+   *************** *** 54,66 **** Downloads - - Bug Reports - - - Submit Patches - - - Browse CVS -   --- 42,45 ---- *************** *** 74,80 **** Archives - - - Post --- 53,56 ---- From kbk at users.sourceforge.net Thu Dec 18 20:18:17 2003 From: kbk at users.sourceforge.net (Kurt B. Kaiser) Date: Thu Dec 18 20:18:20 2003 Subject: [Idle-dev] CVS: website index.html,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/website In directory sc8-pr-cvs1:/tmp/cvs-serv27569 Modified Files: index.html Log Message: Fix typo M index.html Index: index.html =================================================================== RCS file: /cvsroot/idlefork/website/index.html,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** index.html 19 Dec 2003 00:59:59 -0000 1.4 --- index.html 19 Dec 2003 01:18:15 -0000 1.5 *************** *** 170,174 ****

Patches !

The Python Patch Tracer can be found here.. --- 170,174 ----

Patches !

The Python Patch Tracker can be found here.. From kbk at users.sourceforge.net Thu Dec 18 21:43:13 2003 From: kbk at users.sourceforge.net (Kurt B. Kaiser) Date: Thu Dec 18 21:43:17 2003 Subject: [Idle-dev] CVS: website index.html,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/website In directory sc8-pr-cvs1:/tmp/cvs-serv8460 Modified Files: index.html Log Message: Fix Martin M index.html Index: index.html =================================================================== RCS file: /cvsroot/idlefork/website/index.html,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** index.html 19 Dec 2003 01:18:15 -0000 1.5 --- index.html 19 Dec 2003 02:43:10 -0000 1.6 *************** *** 129,133 **** integration and persistent breakpoints).

! Scott David Daniels, Hernan Foffani, Christos Georgiou, Martin v. L?wis, Jason Orendorff, Noam Raphael, Josh Robb, Nigel Rowe, and Bruce Sherwood have submitted useful patches. Thanks, guys! --- 129,133 ---- integration and persistent breakpoints).

! Scott David Daniels, Hernan Foffani, Christos Georgiou, Martin v. Löwis, Jason Orendorff, Noam Raphael, Josh Robb, Nigel Rowe, and Bruce Sherwood have submitted useful patches. Thanks, guys! From kbk at shore.net Fri Dec 19 11:45:24 2003 From: kbk at shore.net (Kurt B. Kaiser) Date: Fri Dec 19 11:45:30 2003 Subject: [Idle-dev] modifying color rules In-Reply-To: <20031217222223.85980.qmail@web11101.mail.yahoo.com> (Luke Bradley's message of "Wed, 17 Dec 2003 14:22:23 -0800 (PST)") References: <20031217222223.85980.qmail@web11101.mail.yahoo.com> Message-ID: Luke Bradley writes: > I'm interested in changing the coloring rules in idle for a > different type of file, one that includes python embedded in > HTML. This file type is my own creation and has a different suffix. > I was wondering if any of the developers being familiar with the > code structure know of a quick way to apply a different set of > coloring rules for a different type of file, or a good place to jump > into the code for this type of thing. There hasn't been any attempt to generalize IDLE to handle different languages. However, you should not have much difficulty doing what you want to do. Take a look at EditorWindow.py:EditorWindow.ispythonsource(). Colorizing is handled by EditorWindow.py and ColorDelegator.py. File I/O is handled by IOBinding.py. The color configuration is loaded from config-highlight.def by configHandler.py when an EditorWindow is initialized. config-highlight.def is set up by configDialog.py. IDLE can modify itself. Since we currently can have only one instance of IDLE running a subprocess, what I often do is start a copy of IDLE with the -n switch and use that to edit the code. Then I use another copy w/o the switch for testing. If IDLE is started with the -n switch, the debugger will trace through IDLE itself. Otherwise, it will only trace user code. -- KBK