From nir1408 at hotmail.com  Mon Feb  2 10:04:13 2004
From: nir1408 at hotmail.com (Nir of the Waves)
Date: Mon Feb  2 10:11:36 2004
Subject: [Idle-dev] key problems with idle 1.0.2
Message-ID: <BAY10-DAV17Wd7KKQpQ0003f4cb@hotmail.com>

Hello,

 

I use idle 1.0.2 on Windows XP.

For some strange reason key bindings don't work.

 

Nothing!

 

e.g.: Clicking <CTRL+Z> should undo but it does nothing

 

Is this a known problem?

How do I work around that?

 

Please reply to nir1408@hotmail.com

Nir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20040202/43071406/attachment.html
From kbk at shore.net  Mon Feb  2 15:14:21 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon Feb  2 15:14:27 2004
Subject: [Idle-dev] key problems with idle 1.0.2
In-Reply-To: <BAY10-DAV17Wd7KKQpQ0003f4cb@hotmail.com> (Nir of the Waves's
	message of "Mon, 2 Feb 2004 17:04:13 +0200")
References: <BAY10-DAV17Wd7KKQpQ0003f4cb@hotmail.com>
Message-ID: <87ad41utlu.fsf@hydra.localdomain>

"Nir of the Waves" <nir1408@hotmail.com> writes:

> I use idle 1.0.2 on Windows XP.
>
> For some strange reason key bindings don't work.

[...]

> e.g.: Clicking <CTRL+Z> should undo but it does nothing
>
>  
>
> Is this a known problem?
>
> How do I work around that?

Is your shift lock on?  It's <ctrl-z> not <ctrl-Z>.

-- 
KBK

From carlo.verre at telecomitalia.it  Tue Feb  3 09:34:40 2004
From: carlo.verre at telecomitalia.it (Verre Carlo)
Date: Tue Feb  3 20:43:13 2004
Subject: [Idle-dev] Small wish for Idle...
Message-ID: <AEAABDA891DF454FB8970EA7D27C1141022E6B@PTPEVS004RM001.idc.cww.telecomitalia.it>

I use Python 2.3.3 & Idle 1.0.2 in my system programmer job, it's true
RAD! Many thanks!

Only a small wish for next version of Idle. Often, under MS.Windows
environment, I write Python scripts as .BAT files, but if extension is
not .PY[W] I don't get text colorization. Colorization should be nice
also for configuration files, to know at first glance the comment '#...'
rows. I think colorization should be a feature you can freely turn on or
off.

Many thanks and best regards

 Carlo Verre
 IT Telecom spa - OI.EDC.PD
 viale Parco de' Medici 61 - 00148 Roma
 Corpo C - Piano 1 - Stanza 1023
 06.368.90513 - 335.1345856
 mailto:carlo.verre@telecomitalia.it

 






--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to webmaster@telecomitalia.it.
        Thank you
                                        www.telecomitalia.it
--------------------------------------------------------------------



From kbk at shore.net  Sun Feb  8 14:48:44 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sun Feb  8 14:48:48 2004
Subject: [Idle-dev] Re: Clearing IDLE's screen?
In-Reply-To: <4f0a9fdb.0402080107.3800b86e@posting.google.com> (Miki
	Tebeka's message of "8 Feb 2004 01:07:29 -0800")
References: <4f0a9fdb.0402080107.3800b86e@posting.google.com>
Message-ID: <87k72x73oj.fsf@hydra.localdomain>

The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.

miki.tebeka@zoran.com (Miki Tebeka) writes:

> I'd like to bind <CTRL+L> so that it will clear IDLE's screen (in the
> interactive prompt).
> Any pointers/suggetions?

Try this:

def clear():
    for i in range(60):
        print

If that is adequate, then you should be able to write an extension
for IDLE which would bind this function to a key.

Read .../idlelib/extend.txt for further information.

Note that if you use this approach, previous entries into the Shell
window can be retrieved by scrolling up and/or using the "View Last
Restart / F6" feature.  This is useful to recall code to the command
line for re-evaluation.

The downside is the buffer can get pretty large.  You have to decide
if that's a problem.  It hasn't been for me.  If you have an Edit
window open, you can always close the Shell window occasionally and
reopen it from the Run menu.

If you really want to clear the buffer for the Shell window, then the
Tkinter Text widget would have to be truncated.  That involves a
deeper understanding of IDLE, particularly EditWindow.py,
OutputWindow.py, and PyShell.py.  It is conceivable that it could be
done as an extension.


===

I have been planning on implementing an integrated Shell Clear
capability in IDLE 1.1 which would truncate the Shell Text widget.
Just re-opening the Shell window would probably move it on the screen,
so that is not very attractive.

The question for the list is, should Clear be orthogonal to Reset or
should Clear also do a Reset?

Other comments?

-- 
KBK

From jbrandmeyer at earthlink.net  Wed Feb 18 18:28:45 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Thu Feb 19 09:21:58 2004
Subject: [Idle-dev] Built-in help under Mac OS X
Message-ID: <1077146925.16622.10.camel@illuvatar>

Under Apple's OSX operating system, the variable sys.platform is named
'darwin'.  In at least one place, idle makes a test to see if the
current platform is MS Windows by checking for the substring 'win' in
sys.platform, which leads to incorrect behavior on the Mac.

In particular, in lib/python2.3/idlelib/EditorWindow.py, member function
EditorWindow.python_docs() behaves incorrectly on OS X.  I believe that
if the test for MS Windows is completely removed that you will get
correct behavior on all platforms, based on my reading of the webbrowser
module source.

Please change that function to the following (near line 313):

    def python_docs(self, event=None):
            webbrowser.open(self.help_url)
            return "break"

Thanks,
Jonathan Brandmeyer



From kbk at shore.net  Thu Feb 19 14:14:07 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu Feb 19 14:14:12 2004
Subject: [Idle-dev] Built-in help under Mac OS X
In-Reply-To: <1077146925.16622.10.camel@illuvatar> (Jonathan Brandmeyer's
	message of "Wed, 18 Feb 2004 18:28:45 -0500")
References: <1077146925.16622.10.camel@illuvatar>
Message-ID: <87oerudgqo.fsf@hydra.localdomain>

Jonathan Brandmeyer <jbrandmeyer@earthlink.net> writes:

> Under Apple's OSX operating system, the variable sys.platform is named
> 'darwin'.  In at least one place, idle makes a test to see if the
> current platform is MS Windows by checking for the substring 'win' in
> sys.platform, which leads to incorrect behavior on the Mac.
>
> In particular, in lib/python2.3/idlelib/EditorWindow.py, member function
> EditorWindow.python_docs() behaves incorrectly on OS X.  I believe that
> if the test for MS Windows is completely removed that you will get
> correct behavior on all platforms, based on my reading of the webbrowser
> module source.
>
> Please change that function to the following (near line 313):
>
>     def python_docs(self, event=None):
>             webbrowser.open(self.help_url)
>             return "break"

Argh.  Thanks for the report.  Please enter it into the Python bug
tracker at

http://sourceforge.net/tracker/?group_id=5470&atid=105470

Use the 'IDLE' category.

That way it won't get lost.

-- 
KBK

From dpennell at guardnet.com  Thu Feb 19 18:15:27 2004
From: dpennell at guardnet.com (David Pennell)
Date: Thu Feb 19 18:17:11 2004
Subject: [Idle-dev] Where are the global and local variables kept?
In-Reply-To: <87oerudgqo.fsf@hydra.localdomain>
References: <1077146925.16622.10.camel@illuvatar>
	<87oerudgqo.fsf@hydra.localdomain>
Message-ID: <80D0470F-6331-11D8-8699-003065B1C840@guardnet.com>

When I used he debugger, 90%+ of the variables and messages I got 
weren't anything to do with my program. They were always variables from 
pyshell and IDLE itself. For that reason, I gave up on the debugger 
completely a long time ago. Periodically I've checked it out and it 
still does that. I use stuff in my programs now to debug, basically.
So first, does anyone get anything at all out of the debugger, and if 
so, what and how?

Secondly, is there any kind of fix or workaround already out there for 
this? I am not sure where and how IDLE stores the variables it displays 
with the debugger.


From kbk at shore.net  Thu Feb 19 21:50:33 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu Feb 19 21:50:42 2004
Subject: [Idle-dev] Where are the global and local variables kept?
In-Reply-To: <80D0470F-6331-11D8-8699-003065B1C840@guardnet.com> (David
	Pennell's message of "Thu, 19 Feb 2004 15:15:27 -0800")
References: <1077146925.16622.10.camel@illuvatar>
	<87oerudgqo.fsf@hydra.localdomain>
	<80D0470F-6331-11D8-8699-003065B1C840@guardnet.com>
Message-ID: <87smh6o45i.fsf@hydra.localdomain>

David Pennell <dpennell@guardnet.com> writes:

> When I used he debugger, 90%+ of the variables and messages I got
> weren't anything to do with my program. They were always variables
> from pyshell and IDLE itself. For that reason, I gave up on the
> debugger completely a long time ago. Periodically I've checked it out
> and it still does that. I use stuff in my programs now to debug,
> basically.
> So first, does anyone get anything at all out of the debugger, and if
> so, what and how?

I'd suggest that you upgrade to Python 2.3.3 and try IDLE 1.0.2.  
You should find that the debugger no longer traces though IDLE.
This has been true since IDLEfork was integrated into Python 2.3.1.

> Secondly, is there any kind of fix or workaround already out there
> for this? I am not sure where and how IDLE stores the variables it
> displays with the debugger.

The variables are extracted from the stack frames.  IDLE now has code
to ignore those stack frames associated with IDLE itself.

Python has great introspection.  That, plus print statements, can be a
more efficient way to debug user code.  But there are times when the
debugger is useful, particularly if you don't know what you are
looking for.  The current debugger has persistent breakpoints which
are stored between sessions.  You may also find the stack viewer
helpful.

Please let me know if you have futher problems.

-- 
KBK

From marilyn at deliberate.com  Thu Feb 19 18:44:38 2004
From: marilyn at deliberate.com (Marilyn Davis)
Date: Fri Feb 20 10:50:38 2004
Subject: [Idle-dev] Setting argv in idle
Message-ID: <Pine.LNX.4.44.0402191540350.11161-100000@Kuna>


My friends and I can't find a way to set up command line arguments
to feed into our python programs while using idle.

This would be a useful feature.

It's easy to work-around this but, still, it would be nice.

Thank for the language and idle.

Marilyn Davis




From kbk at shore.net  Fri Feb 20 11:56:21 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Fri Feb 20 11:56:27 2004
Subject: [Idle-dev] Setting argv in idle
In-Reply-To: <Pine.LNX.4.44.0402191540350.11161-100000@Kuna> (Marilyn
	Davis's message of "Thu, 19 Feb 2004 15:44:38 -0800 (PST)")
References: <Pine.LNX.4.44.0402191540350.11161-100000@Kuna>
Message-ID: <878yixofka.fsf@hydra.localdomain>

Marilyn Davis <marilyn@deliberate.com> writes:

> My friends and I can't find a way to set up command line arguments
> to feed into our python programs while using idle.
>
> This would be a useful feature.
>
> It's easy to work-around this but, still, it would be nice.

GvR would like this, also:

https://sourceforge.net/tracker/index.php?func=detail&aid=441575&group_id=9579&atid=359579

-- 
KBK

From tgrzybow at rcn.com  Fri Feb 20 17:01:21 2004
From: tgrzybow at rcn.com (tgrzybow)
Date: Fri Feb 20 15:58:02 2004
Subject: [Idle-dev] Segmentation Fault(s) on RH WS3
In-Reply-To: <E1AuE61-0002DK-HX@mail.python.org>
References: <E1AuE61-0002DK-HX@mail.python.org>
Message-ID: <403683B1.5050303@rcn.com>

Hi:

I have installed python 2.3.3 from source on RH Professional Workstation 
e3, and I am trying to get IDLE running. No matter what I do, I get a 
segmentation fault. After trying a number of things, I have even gone so 
far as to install tcl and tk from source as well - still the same 
problem. Is there any way to debug this to determine how and where this 
is happening so that I may correct it without shooting in the dark?

Thanks much,

Thomas Grzybowski
Gestalt Biotec




From kbk at shore.net  Fri Feb 20 17:02:23 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Fri Feb 20 17:02:27 2004
Subject: [Idle-dev] Segmentation Fault(s) on RH WS3
In-Reply-To: <403683B1.5050303@rcn.com> (tgrzybow@rcn.com's message of "Fri,
	20 Feb 2004 17:01:21 -0500")
References: <E1AuE61-0002DK-HX@mail.python.org> <403683B1.5050303@rcn.com>
Message-ID: <87k72hmmts.fsf@hydra.localdomain>

tgrzybow <tgrzybow@rcn.com> writes:

> I have installed python 2.3.3 from source on RH Professional
> Workstation e3, 

The Fedora binary rpm doesn't work?  What about the .src.rpm?

> and I am trying to get IDLE running. No matter what I do, I get a
> segmentation fault. After trying a number of things, I have even
> gone so far as to install tcl and tk from source as well - still the
> same problem. Is there any way to debug this to determine how and
> where this is happening so that I may correct it without shooting in
> the dark?

I'm assuming that this only happens when you try to start IDLE, and that
python itself is working OK.  Please confirm you are actually running
Python 2.3.3 and RH hasn't found some older version.


First thing I would try is to start IDLE with

python [path to Python tree]/Lib/idlelib/idle.py -n

which will start it without the subprocess.  That should at least
confirm that your Tcl/Tk installation is OK.

Please copy/paste full error messages here and we can go from there.

-- 
KBK

From noreply at sourceforge.net  Fri Feb 20 11:54:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 10:30:26 2004
Subject: [Idle-dev] [ idlefork-Feature Requests-441575 ] Better Run Script
	Interface
Message-ID: <E1AuDuc-0004yb-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #441575, was opened at 2001-07-15 22:46
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=441575&group_id=9579

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Run Script Interface

Initial Comment:
TeachScheme has an interesting mode that I like.  Whenever you run a script, the "shell" environment is created afresh, and the shell can then be used to inspect effects of the script. 

The whole interface for running scripts needs to be changed; I'd like to see a one-key binding that pops up a dialog where you can specify - whether to use debug mode - command line arguments Pythonwin has this (plus an option to suppress the dialog and use last time's defaults). 

--Guido van Rossum 
(home page: http://www.python.org/~guido/)

14 July 2001

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-02-20 11:54

Message:
Logged In: YES 
user_id=149084

Marilyn Davis <marilyn@deliberate.com> writes: [Idle-dev]

> My friends and I can't find a way to set up command line arguments
> to feed into our python programs while using idle.
>
> This would be a useful feature.
>
> It's easy to work-around this but, still, it would be nice.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=441575&group_id=9579

From marilyn at deliberate.com  Fri Feb 20 13:15:08 2004
From: marilyn at deliberate.com (Marilyn Davis)
Date: Sat Feb 21 10:30:27 2004
Subject: [Idle-dev] Setting argv in idle
In-Reply-To: <878yixofka.fsf@hydra.localdomain>
Message-ID: <Pine.LNX.4.44.0402201013290.11161-100000@Kuna>


Thanks.  The __future__ looks good.

Marilyn

On Fri, 20 Feb 2004, Kurt B. Kaiser wrote:

> Marilyn Davis <marilyn@deliberate.com> writes:
> 
> > My friends and I can't find a way to set up command line arguments
> > to feed into our python programs while using idle.
> >
> > This would be a useful feature.
> >
> > It's easy to work-around this but, still, it would be nice.
> 
> GvR would like this, also:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=441575&group_id=9579&atid=359579
> 
> 

-- 


From tgrzybow at rcn.com  Sat Feb 21 16:04:09 2004
From: tgrzybow at rcn.com (tgrzybow)
Date: Sat Feb 21 15:00:44 2004
Subject: [Idle-dev] Re: IDLE-dev Digest, Vol 7, Issue 7
In-Reply-To: <E1AuaXc-0003P5-Dc@mail.python.org>
References: <E1AuaXc-0003P5-Dc@mail.python.org>
Message-ID: <4037C7C9.8090608@rcn.com>

idle-dev-request@python.org wrote:

>Send IDLE-dev mailing list submissions to
>	idle-dev@python.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://mail.python.org/mailman/listinfo/idle-dev
>or, via email, send a message with subject or body 'help' to
>	idle-dev-request@python.org
>
>You can reach the person managing the list at
>	idle-dev-owner@python.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of IDLE-dev digest..."
>
>
>Today's Topics:
>
>   1. Segmentation Fault(s) on RH WS3 (tgrzybow)
>   2. Re: Segmentation Fault(s) on RH WS3 (Kurt B. Kaiser)
>   3. [ idlefork-Feature Requests-441575 ] Better Run Script
>      Interface (SourceForge.net)
>   4. Re: Setting argv in idle (Marilyn Davis)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 20 Feb 2004 17:01:21 -0500
>From: tgrzybow <tgrzybow@rcn.com>
>Subject: [Idle-dev] Segmentation Fault(s) on RH WS3
>To: idle-dev@python.org
>Message-ID: <403683B1.5050303@rcn.com>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>Hi:
>
>I have installed python 2.3.3 from source on RH Professional Workstation 
>e3, and I am trying to get IDLE running. No matter what I do, I get a 
>segmentation fault. After trying a number of things, I have even gone so 
>far as to install tcl and tk from source as well - still the same 
>problem. Is there any way to debug this to determine how and where this 
>is happening so that I may correct it without shooting in the dark?
>
>Thanks much,
>
>Thomas Grzybowski
>Gestalt Biotec
>
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 20 Feb 2004 17:02:23 -0500
>From: kbk@shore.net (Kurt B. Kaiser)
>Subject: Re: [Idle-dev] Segmentation Fault(s) on RH WS3
>To: tgrzybow <tgrzybow@rcn.com>
>Cc: idle-dev@python.org
>Message-ID: <87k72hmmts.fsf@hydra.localdomain>
>Content-Type: text/plain; charset=us-ascii
>
>tgrzybow <tgrzybow@rcn.com> writes:
>
>  
>
>>I have installed python 2.3.3 from source on RH Professional
>>Workstation e3, 
>>    
>>
>
>The Fedora binary rpm doesn't work?  What about the .src.rpm?
>
>  
>
>>and I am trying to get IDLE running. No matter what I do, I get a
>>segmentation fault. After trying a number of things, I have even
>>gone so far as to install tcl and tk from source as well - still the
>>same problem. Is there any way to debug this to determine how and
>>where this is happening so that I may correct it without shooting in
>>the dark?
>>    
>>
>
>I'm assuming that this only happens when you try to start IDLE, and that
>python itself is working OK.  Please confirm you are actually running
>Python 2.3.3 and RH hasn't found some older version.
>
>
>First thing I would try is to start IDLE with
>
>python [path to Python tree]/Lib/idlelib/idle.py -n
>
>which will start it without the subprocess.  That should at least
>confirm that your Tcl/Tk installation is OK.
>
>Please copy/paste full error messages here and we can go from there.
>
>  
>
Hi:

I must have goofed myself up earlier. I have reinstalled RH Workstation 
e3, recompiled and reinstalled tcl, tk, and python 2.3, and now can 
successfully bring up IDLE 1.0.

Thanks for the offer of help!

Thanks,

Thomas Grzybowski




From ajsiegel at optonline.net  Sun Feb 22 16:24:36 2004
From: ajsiegel at optonline.net (Arthur)
Date: Sun Feb 22 23:12:32 2004
Subject: [Idle-dev] User-defined "keywords"
Message-ID: <0HTI00ECT8SY5N@mta4.srv.hcvlny.cv.net>


Hi all.

I had found that I missed, in IDLE, the ability to define domain specific
keywords for highlighting, ala Scite and TextPad.

I discover that doing so by hand is quite enough:

 -  provide ColorDelegator.py with lists of keywords,
    e.g.  KEYWORD2 = ["newkw1", newkw2"]

 -  add a line to make_pat:
        kw2= r"\b" + any("KEYWORD2", pygeokeys.KEYWORD2) + r"\b" 

 -  edit the make_pat return
        return kw + "|" + kw2 ....

-   provide self.tagdefs in LoadTagDefs a tag:
        "KEYWORD2": {'background':'ffffff','foreground':'#007FFF'}, 

The end.

What I am missing is only the ability to provide other users this option in
a reasonable way.  What would make sense to me is to the effect of a
config-kws.cfg in user Home with a simple syntax like:

[KEYWORD2}
'newkw1'
'newkw2'

Some default coloring scheme for a few levels of user-defined keywords.

And then the expansion of the HighLighting window to allow users to
customize the coloring of user-defined keyword levels.

Am I making sense?

Should it be pursued?

Art 



From a.d.schapira at worldnet.att.net  Mon Feb 23 14:26:00 2004
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Tue Feb 24 09:56:49 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
Message-ID: <403A53C8.70203@worldnet.att.net>

I downloaded and installed python 2.3.3 source, built, and installed it 
with idle 1.0.2 under RH linux 9 w/kernel 2.4.20-28.9.

The first time I ran idle, it worked fine, and I selected the default 
fonts, etc.  Subsequently, idle won't start in subproces mode.  I get 
the error output below every time.  Using -n as suggested works ok.

How do I clear the port in use?
How do I prevent this from happening again?

Thanks.
	-Al Schapira, a.d.schapira@worldnet.att.net

> [ads@ADS1 ads]$ idle
> IDLE socket error: Address already in use, retrying...
> IDLE socket error: Address already in use, retrying...
> IDLE socket error: Address already in use, retrying...
>  
> IDLE cannot run.
>  
> IDLE needs to use a specific TCP/IP port (8833) in order to communicate with
> its Python execution server.  IDLE is unable to bind to this port, and so
> cannot start. Here are some possible causes of this problem:
>  
>   1. TCP/IP networking is not installed or not working on this computer
>   2. Another program (another IDLE?) is running that uses this port
>   3. Personal firewall software is preventing IDLE from using this port
>  
> Run IDLE with the -n command line switch to start without a subprocess
> and refer to Help/IDLE Help "Running without a subprocess" for further
> details.
>  
> [ads@ADS1 ads]$ uname -a
> Linux ADS1 2.4.20-28.9 #1 Thu Dec 18 13:45:22 EST 2003 i686 i686 i386 GNU/Linux
> [ads@ADS1 ads]$



From ajsiegel at optonline.net  Wed Feb 25 09:55:19 2004
From: ajsiegel at optonline.net (Arthur)
Date: Wed Feb 25 09:55:22 2004
Subject: [Idle-dev] re: User-defined "keywords"
Message-ID: <0HTN00IZZAS37A@mta2.srv.hcvlny.cv.net>

I had written -

>Hi all.

>I had found that I missed, in IDLE, the ability to define domain 
>specific keywords for highlighting, ala Scite and TextPad.

>I discover that doing so by hand is quite simple enough:

> -  provide ColorDelegator.py with lists of keywords,
>    e.g.  KEYWORD2 = ["newkw1", newkw2"]

> -  add a line to make_pat:
>        kw2= r"\b" + any("KEYWORD2", pygeokeys.KEYWORD2) + r"\b" 

> -  edit the make_pat return
>        return kw + "|" + kw2 ....

>-   provide self.tagdefs in LoadTagDefs a tag:
>        "KEYWORD2": {'background':'ffffff','foreground':'#007FFF'},

>The end


A little further delving let's me understand that what I am after is even
closer than I had originally thought. (I am really just getting my feet wet
as to the features of the new Idle).

By simply placing a config-extensions.cfg file in my .idlerc directory with
the format

[Keywords2]
kw2=['newkw2_1','newkw2_2']

[Keywords3]
Kw3=['newkw3_1','newkw3_2']

the new levels of "keywords" become available to ColorDelegator.py.

add to make_pat:

kw2= r"\b" + any("KEYWORD2",
idleConf.GetOption('extensions','Keyword2','kw2')) + \b"

etc. (how many levels should be made possible?)

edit the make_pat return to:

    return kw + "|" + kw2 + ...

And use a config-highlight.cfg file in .ilderc to specify color options for
the extensions keyword levels and have them picked up in the LoadTags method
(2 lines of code).

It seems to me (this isn't fully tested) if no such files exist, there is no
impact, i.e.  no additional testing code necessary.  If the files are there
they have the intended functionality.  (It may however be cleanest, or even
necessary to add kw2 ...  to the default highlighting themes). 

If the extension and user files are not present, we go on exactly as before.

Seems to me a no lose situation: negligible touching of existing code,
useful and high impact feature addition. 

So - 

Am I going over old ground, somehow?

Is the availability of this feature consistent with Idle intentions?  It
seems to me it is  - consistent, for example, with the ability to add user
defined help files.

Is there a technical or other downside I am missing? Perhaps what I am after
can be accomplished purely as an extension with no need to touch the code
base? If so, I don't see it.

Art




From kbk at shore.net  Wed Feb 25 16:04:31 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Wed Feb 25 16:05:40 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
In-Reply-To: <403A53C8.70203@worldnet.att.net> (Al Schapira's message of
	"Mon, 23 Feb 2004 14:26:00 -0500")
References: <403A53C8.70203@worldnet.att.net>
Message-ID: <87d682euqo.fsf@hydra.localdomain>

Al Schapira <a.d.schapira@worldnet.att.net> writes:

> I downloaded and installed python 2.3.3 source, built, and installed
> it with idle 1.0.2 under RH linux 9 w/kernel 2.4.20-28.9.
>
> The first time I ran idle, it worked fine, and I selected the default
> fonts, etc.  Subsequently, idle won't start in subproces mode.  I get
> the error output below every time.  Using -n as suggested works ok.
>
> How do I clear the port in use?
> How do I prevent this from happening again?

Make sure that there is only one instance of the IDLE GUI running on
your system.  The current design can only support one, though there
are plans to change that in the future.  I want to be sure that IDLE
is robust with one instance, especially on Windows, before I add more
ports.

On Linux or the BSDs, if you do  

     ps aux

you should see no python processes when IDLE isn't running, and two
when it is.  (On Windows, you'll see three.)  Kill any extra ones and
try again:

     kill -KILL xxxx

where xxxx is the pid of the python process.

Let me know if you have further problems.  Save any error messages and
a    ps aux   trace.
-- 
KBK

From yulzbr1 at rhein-neckar.netsurf.de  Wed Feb 25 18:17:00 2004
From: yulzbr1 at rhein-neckar.netsurf.de (Erica Stahl)
Date: Thu Feb 26 01:21:45 2004
Subject: [Idle-dev] Invest Source research alerts for maximum capital gains
	jm
Message-ID: <a-76-9wyd0$602@6ylumru>

Wall Street Financial Times Newsletter

Specializing in Undervalued Small Cap Stocks for Immediate Breakout

We have the #1 track record for our picks in 2004:

GETC at .12		Currently .50	High .68 UP 467%
TLPE at 1.12	Currently 3.35	High 4.40 UP 293%
SWYC at .18 	Currently .71	High .81 UP 350%
DNYY at .47	Currently 1.42	High 1.85 UP 294%

Immediate Investor Recommendation
Our Hottest Sales and Earnings Play
Projected to Triple in 7 Days:

Life Energy and Technology Holdings, Inc.
(OTCBB: LETH)

Price--- 1.20
Sales Orders Received '03--- over $150 Million +300% growth vs. '02
Est. Sales Growth '04--- +165%
Results from latest 10-Q:
Total Assets--- 36.8 million vs. 16.8 million
Cash--- 23.4 million vs. deficit
Shareholders Equity--- 12.0 million vs. 2.2 million
Shares Outstanding--- 29 mill
Est. Shares in Float--- 7 mill
Proj. Value Per Share--- 3.25 -- 3.50
Rating--- Urgent Buy

LETH is thriving as an emerging world leader in the conversion of waste 
materials into electrical energy by utilizing their Biosphere Process System, 
making them the hottest undervalued stock at this price level where shares 
are ready to explode on huge investor attention.

Sales have rocketed beyond all estimates for LETH with no signs of 
slowing. The numbers continue to stack-up as sales orders for the Biosphere 
exceed $150 Million over the past year while the stock price doesn't yet 
reflect the appearance of these impressive figures on an upcoming balance 
sheet. We are not the first to uncover this phenomenon as the stock is under 
accumulation, but we are acting aggressively on this recently filed data.

The unique proprietary technology of the Biosphere fills an urgent 
worldwide need for cost-effective renewable energy sources and a 
corresponding universal need to solve critical problems in the disposal of 
waste. The Biosphere System provides the highest level of innovative 
technology while securing worldwide acceptance for a revolutionary product 
designed to significantly impact the global waste problem while 
simultaneously generating electricity. 

The Biosphere System enables LETH to draw revenue from the disposal of 
various types of waste at 5 to 7 tons per hour including such materials as:
Municipal Solid Waste, refinery wastes, agricultural surpluses or effluents, 
medical waste, industrial waste, shale oil, sour natural gas, and the huge 
market of used tires are all converted in the Biosphere Process. LETH also
profits from the sale of electricity created from the waste conversion on a 
continuous basis by generating 5 to 10 mega-watts per hour of electricity 
which is then sold to replenish the local or national grid. 

LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a 
leader and one of the largest providers in environmental, mechanical, and 
electrical management consulting services primarily for the US Government 
with annual sales of $800 Million. Tetra Tech will coordinate permitting, 
installation and continuous worldwide monitoring of the Biosphere Process 
System for LETH. Tetra Tech is now in the process of obtaining Department 
of Environmental Quality permitting for the Biosphere Process in the state of 
Louisiana. This is a monumental event for LETH which opens the 
floodgates for major project revenues in Louisiana while having a parallel 
effect on LETH stock in the form of a huge near-term announcement. 

LETH has begun to catch the profit-making attention of investors by 
embracing a major foothold on the global waste problem while a major push 
for generating electricity from alternative sources continues to be the hot 
topic due to shortages and massive power failures. LETH contains all the 
ingredients for major profits as global demand to solve two crisis areas, 
waste and electrical energy, reaches unprecedented levels. We view this 
perfectly timed convergence of events as the catalyst for additional contracts 
that will perpetuate the shattering of the Company's own sales records. We 
are seeing substantial gains for early investors in a ground floor opportunity 
that carries our highest rating for short-term trading profits.

Required LETH information: Certain statements contained in this newsletter 
may be forward looking statements within the meaning of The Private 
Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", 
"may", "will", and "intend" or similar terms may identify these statements 
We are not a registered investment advisor or a broker dealer. This is not an 
offer to buy or sell securities. No recommendation that the securities of the 
companies profiled should be purchased, sold or held by individuals or 
entities that learn of the profiled companies. This is an independent 
electronic publication that was paid five thousand dollars by an unaffiliated 
third party for the preparation of this company information. Be advised that 
investments in companies profiled are considered to be high-risk and use of 
the content provided is for information purposes only. If anyone decides to 
act as an investor they are advised not to invest without the proper guidance 
from a financial advisor or a registered financial broker. If any party decides 
to participate as an investor then it will be that investor's sole risk. Be 
advised that the purchase of such high-risk securities may result in the loss 
of some or all of the investment. Investors should not rely solely on the 
information presented. Rather, investors should use the information provided 
in this newsletter as a starting point for doing additional independent 
research on the profiled companies in order to allow the investor to form 
their own opinion regarding investing in the profiled companies. Factual 
statements made about the profiled companies are made as of the date stated 
and are subject to change without notice. Investing in micro-cap securities is 
highly speculative and carries an extremely high degree of risk. All 
information provided about the profiled companies may include information 
provided by outside sources, such as research reports, public filings, and 
information provided by management of the profiled company. 

ucrjpbyw yqqiudr txf  n may zymtfkb zxideixsvq zamiby
From tas at iis.fhg.de  Thu Feb 26 03:36:30 2004
From: tas at iis.fhg.de (Klaus Taschka)
Date: Thu Feb 26 03:39:06 2004
Subject: [Idle-dev] Re: Information
In-Reply-To: <200402251144.i1PBiqn7003982@mailgwb1.fraunhofer.de>
References: <200402251144.i1PBiqn7003982@mailgwb1.fraunhofer.de>
Message-ID: <403DB00E.9020105@iis.fhg.de>

ok.

Klaus Taschka

idle-dev@python.org schrieb:

>------------------  Virus-Warnung/virus alert (mailgateway mailgwb1)
>
>Found virus WORM_MYDOOM.F in file photo.exe (in photo.zip)
>The file photo.zip is moved to /etc/iscan/virus/virCDAUTa4Kh.
>
>Die Email enthielt einen Virus! Das Attachment mit dem Virus wurde in Quarantaene genommen. Bei Fragen wenden Sie sich bitte an Ihren IT-Manager oder gegebenenfalls NOC-Helpdesk (http://www.noc.fraunhofer.de oder email:NOC-Helpdesk@fhg.de). If you have questions, please contact your local IT manager or NOC helpdesk (http://www.noc.fraunhofer.de or email:NOC-Helpdesk@fhg.de).
>
>---------------------------------------------------------
>  
>
>------------------------------------------------------------------------
>
>Everything ok?
>
>  
>
>------------------------------------------------------------------------
>
>
>------------------  Virus-Warnung/virus alert (mailgateway mailgwb1)
>
>photo.zip is removed from here because it contains a virus.
>
>---------------------------------------------------------
>



From tcm-users-request at cs.utwente.nl  Thu Feb 26 11:28:42 2004
From: tcm-users-request at cs.utwente.nl (tcm-users-request@cs.utwente.nl)
Date: Thu Feb 26 11:28:49 2004
Subject: [Idle-dev] Your mail to tcm-users-request@listserv.cs.utwente.nl
In-Reply-To: <200402261628.i1QGSb122496@netlx014.civ.utwente.nl>,
	from idle-dev@python.org
Message-ID: <200402261628.i1QGSgvk001294@utrhcs.cs.utwente.nl>

This pre-recorded message is being sent in response to your recent
email to tcm-users-request@listserv.cs.utwente.nl.

All routine administrative requests (including subscriptions and
unsubscriptions) concerning this mailing list are handled by an
automated server.  Please read this message carefully to find the
information relevant to you.

SUBSCRIBING
===========

To subscribe to tcm-users, send the following in the body (not
the subject line) of an email message to "Majordomo@listserv.cs.utwente.nl":

	subscribe tcm-users

This will subscribe the account from which you send the message to
the tcm-users list.

If you wish to subscribe another address instead (such as a local
redistribution list), you can use a command of the form:

	subscribe tcm-users other-address@your_site.your_net

UNSUBSCRIBING
=============

To unsubscribe from tcm-users, send the following in the body (not
the subject line) of an email message to "Majordomo@listserv.cs.utwente.nl":

	unsubscribe tcm-users

This will unsubscribe the account from which you send the message.
If you are subscribed with some other address, you'll have to send
a command of the following form instead:

	unsubscribe tcm-users other-address@your_site.your_net

If you don't know what address you are subscribed with, you can send
the following command to see who else is on the list (assuming that
information isn't designated "private" by the owner of the list):

	who tcm-users

If you want to search non-private lists at this server, you can do that
by sending a command like:

	which string

This will return a list of all entries on all lists that contain "string".

HELP
====

To find out more about the automated server and the commands it
understands, send the following command to "Majordomo@listserv.cs.utwente.nl":

	help

If you feel you need to reach a human, send email to:

	tcm-users-approval@listserv.cs.utwente.nl


From a.d.schapira at worldnet.att.net  Thu Feb 26 14:50:54 2004
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Thu Feb 26 14:48:41 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833
	w/python 2.3.3
In-Reply-To: <87d682euqo.fsf@hydra.localdomain>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain>
Message-ID: <1077825054.13728.312.camel@ADS1>

Thanks, Kurt,

I did try to kill all python processes, but that did not help.  Of
course, shutting down and restarting linux cleared the port, as
expected.

Subsequently, idle had been working okay through many sequential
invokations, until just now!
I have attached the error output and ps aux output as requested.

Is there anyway to clear the port without shutting down?

	-Al

On Wed, 2004-02-25 at 16:04, Kurt B. Kaiser wrote:
> Al Schapira <a.d.schapira@worldnet.att.net> writes:
> 
> > I downloaded and installed python 2.3.3 source, built, and installed
> > it with idle 1.0.2 under RH linux 9 w/kernel 2.4.20-28.9.
> >
> > The first time I ran idle, it worked fine, and I selected the default
> > fonts, etc.  Subsequently, idle won't start in subproces mode.  I get
> > the error output below every time.  Using -n as suggested works ok.
> >
> > How do I clear the port in use?
> > How do I prevent this from happening again?
> 
> Make sure that there is only one instance of the IDLE GUI running on
> your system.  The current design can only support one, though there
> are plans to change that in the future.  I want to be sure that IDLE
> is robust with one instance, especially on Windows, before I add more
> ports.
> 
> On Linux or the BSDs, if you do  
> 
>      ps aux
> 
> you should see no python processes when IDLE isn't running, and two
> when it is.  (On Windows, you'll see three.)  Kill any extra ones and
> try again:
> 
>      kill -KILL xxxx
> 
> where xxxx is the pid of the python process.
> 
> Let me know if you have further problems.  Save any error messages and
> a    ps aux   trace.
-------------- next part --------------
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  1384   80 ?        S    Feb25   0:03 init
root         2  0.0  0.0     0    0 ?        SW   Feb25   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kapmd]
root         4  0.0  0.0     0    0 ?        SWN  Feb25   0:00 [ksoftirqd_CPU0]
root         9  0.0  0.0     0    0 ?        SW   Feb25   0:00 [bdflush]
root         5  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kswapd]
root         6  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kscand/DMA]
root         7  0.0  0.0     0    0 ?        SW   Feb25   0:33 [kscand/Normal]
root         8  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kscand/HighMem]
root        10  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kupdated]
root        11  0.0  0.0     0    0 ?        SW   Feb25   0:00 [mdrecoveryd]
root        15  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root        73  0.0  0.0     0    0 ?        SW   Feb25   0:00 [khubd]
root       214  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       215  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       216  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       217  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       218  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       219  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       220  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       221  0.0  0.0     0    0 ?        SW   Feb25   0:00 [kjournald]
root       290  0.0  0.0     0    0 ?        SW   Feb25   0:00 [knodemgrd]
root       611  0.0  0.0  1456  168 ?        S    Feb25   0:00 syslogd -m 0
root       615  0.0  0.0  1380  104 ?        S    Feb25   0:00 klogd -x
rpc        641  0.0  0.0  1552  120 ?        S    Feb25   0:00 portmap
rpcuser    660  0.0  0.0  1528    4 ?        S    Feb25   0:00 rpc.statd
root       716  0.0  0.0  1496    4 ?        S    Feb25   0:00 /sbin/cardmgr
root       740  0.0  0.0  1372  244 ?        S    Feb25   0:00 /usr/sbin/apmd -p 10 -w 5 -W -P /etc/sysconfig/apm-scripts/apmscript
root       777  0.0  0.0  3436    4 ?        S    Feb25   0:00 /usr/sbin/sshd
root       791  0.0  0.0  2076    4 ?        S    Feb25   0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
root       817  0.0  0.0  5980  432 ?        S    Feb25   0:00 sendmail: accepting connections
smmsp      826  0.0  0.0  5740  328 ?        S    Feb25   0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root       836  0.0  0.0 19340    4 ?        S    Feb25   0:00 /usr/bin/spamd -d -c -a              
root       845  0.0  0.0  1416   56 ?        S    Feb25   0:00 gpm -t imps2 -m /dev/mouse
bin        855  0.0  0.0  1928   44 ?        S    Feb25   0:00 /usr/sbin/cannaserver -syslog -u bin
root       866  0.0  0.0  1432  140 ?        S    Feb25   0:00 crond
root       877  0.0  0.4 10100 2400 ?        S    Feb25   0:00 cupsd
wnn        922  0.0  0.0  5172    4 ?        S    Feb25   0:00 /usr/bin/jserver
xfs        999  0.0  0.6  7940 3520 ?        S    Feb25   0:26 xfs -droppriv -daemon
root      1008  0.0  0.0  5800    4 ?        S    Feb25   0:00 smbd -D
daemon    1030  0.0  0.0  1424  152 ?        S    Feb25   0:00 /usr/sbin/atd
root      1039  0.0  2.5 17320 13312 ?       S    Feb25   0:30 /usr/sbin/rcd
root      1049  0.0  0.0  3412   48 ?        S    Feb25   0:00 rhnsd --interval 240
root      1069  0.0  0.0  1360    4 tty1     S    Feb25   0:00 /sbin/mingetty tty1
root      1070  0.0  0.0  1360    4 tty2     S    Feb25   0:00 /sbin/mingetty tty2
root      1071  0.0  0.0  1360    4 tty3     S    Feb25   0:00 /sbin/mingetty tty3
root      1072  0.0  0.0  1360    4 tty4     S    Feb25   0:00 /sbin/mingetty tty4
root      1073  0.0  0.0  1360    4 tty5     S    Feb25   0:00 /sbin/mingetty tty5
root      1074  0.0  0.0  1360    4 tty6     S    Feb25   0:00 /sbin/mingetty tty6
root      1075  0.0  0.0 14128    4 ?        S    Feb25   0:00 /usr/bin/gdm-binary -nodaemon
root      1125  0.0  0.0 14940    4 ?        S    Feb25   0:00 /usr/bin/gdm-binary -nodaemon
root      1126  3.0  3.4 94180 17756 ?       R    Feb25  29:04 /usr/X11R6/bin/X :0 -auth /var/gdm/:0.Xauth vt7
ads       1135  0.0  0.2 18716 1128 ?        S    Feb25   0:04 /usr/bin/gnome-session
ads       1188  0.0  0.0  3068   72 ?        S    Feb25   0:00 /usr/bin/ssh-agent /etc/X11/xinit/Xclients
ads       1193  0.0  0.6 11512 3520 ?        S    Feb25   0:01 /usr/libexec/gconfd-2 11
ads       1195  0.0  0.0  1724   80 ?        S    Feb25   0:00 esd -terminate -nobeeps -as 2 -spawnfd 15
ads       1204  0.0  0.1  6192  944 ?        S    Feb25   0:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=17
ads       1206  0.0  0.0 17148  476 ?        S    Feb25   0:04 gnome-settings-daemon --oaf-activate-iid=OAFIID:GNOME_SettingsDaemon --oaf-ior-fd=14
ads       1211  0.0  0.1  2680  592 ?        S    Feb25   0:00 fam
ads       1216  0.0  0.1  3980  856 ?        S    Feb25   0:07 xscreensaver -nosplash
ads       1219  0.2  0.8 13580 4516 ?        S    Feb25   2:07 metacity --sm-save-file 1061262377-1193-1749723746.ms
ads       1221  0.0  0.6 110144 3324 ?       S    Feb25   0:14 nautilus --sm-config-prefix /nautilus-8j5l2n/ --sm-client-id 117f000001000105732525900000015530003 --screen 0 file:///home
ads       1223  0.1  0.0 16228  468 ?        S    Feb25   1:31 magicdev --sm-config-prefix /magicdev-xqDdi3/ --sm-client-id 117f000001000105732525800000015530002 --screen 0
ads       1225  0.1  1.5 25156 8200 ?        S    Feb25   1:52 gnome-panel --sm-config-prefix /gnome-panel-mL4I2D/ --sm-client-id 117f000001000105732525800000015530001 --screen 0 --profile default
ads       1229  0.1  1.1 23384 6160 ?        S    Feb25   1:17 gnome-terminal --sm-config-prefix /gnome-terminal-Dohifr/ --sm-client-id 117f000001000105768246200000010960000 --screen 0 --use-factory --window-with-profile-internal-id=Default --show-menubar --role=gnome-terminal-1198--858941015-1057682463 --title ads@ADS
ads       1231  0.0  0.4 16612 2060 ?        S    Feb25   0:04 eggcups --sm-config-prefix /eggcups-DiMlP1/ --sm-client-id 117f000001000105732525900000015530004 --screen 0
ads       1233  0.0  0.9 26692 4684 ?        S    Feb25   0:06 /usr/bin/python /usr/bin/rhn-applet-gui --sm-config-prefix /rhn-applet-xXXSvO/ --sm-client-id 117f000001000106125884000000011250001 --screen 0
ads       1246  0.0  0.0  1860    4 ?        S    Feb25   0:00 gnome-pty-helper
ads       1250  0.0  0.0  4388    4 pts/1    S    Feb25   0:00 bash
ads       1282  0.0  0.2 11608 1412 ?        S    Feb25   0:01 /usr/bin/pam-panel-icon --sm-client-id 117f000001000105732526000000015530005
root      1315  0.0  0.0  1412  132 ?        S    Feb25   0:00 /sbin/pam_timestamp_check -d root
ads       1317  0.0  0.4 17300 2300 ?        S    Feb25   0:06 /usr/libexec/battstat-applet-2 --oaf-activate-iid=OAFIID:GNOME_BattstatApplet_Factory --oaf-ior-fd=24
ads       1319  0.0  0.3 16832 1756 ?        S    Feb25   0:02 /usr/libexec/notification-area-applet --oaf-activate-iid=OAFIID:GNOME_NotificationAreaApplet_Factory --oaf-ior-fd=26
ads       1375  0.0  0.0 12296  412 ?        S    Feb25   0:03 kppp
root      1376  0.0  0.0  4920    4 ?        S    Feb25   0:00 /usr/sbin/userhelper -w kppp
root      1379  0.0  2.9 38064 15132 ?       S    Feb25   0:10 kppp
root      1380  0.0  0.0 19860  308 ?        S    Feb25   0:00 kppp
root      1382  0.0  0.0 19600    4 ?        S    Feb25   0:00 kdeinit: Running...       
root      1385  0.0  0.0 21788    4 ?        S    Feb25   0:00 kdeinit: dcopserver --nosid --suicide
root      1388  0.0  0.0 21824    4 ?        S    Feb25   0:00 kdeinit: klauncher        
root      1390  0.0  0.2 23300 1144 ?        S    Feb25   0:05 kdeinit: kded             
root     13150  0.0  0.0  4152    4 pts/1    S    00:33   0:00 su
root     13153  0.0  0.0  4384   88 pts/1    S    00:33   0:00 bash
ads      13728  0.3  4.6 125232 23836 ?      S    01:32   2:58 evolution
ads      13730  0.0  0.2 26292 1176 ?        S    01:32   0:00 /usr/libexec/evolution/1.4/evolution-wombat --oaf-activate-iid=OAFIID:GNOME_Evolution_Wombat_InterfaceCheck --oaf-ior-fd=30
ads      13732  0.0  0.1 23448  648 ?        S    01:33   0:02 /usr/libexec/evolution/1.4/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory --oaf-ior-fd=32
ads      13842  1.2 14.0 166544 72148 ?      S    02:11   9:05 /usr/lib/mozilla-1.2.1/mozilla-bin -UILocale en-US
ads      14957  0.0  0.0 20192   24 ?        S    03:39   0:00 camel-lock-helper
ads      16193  0.0  0.1  4492  876 pts/2    S    06:38   0:00 bash
ads      27375  0.0  0.1  4380  848 pts/0    S    08:46   0:00 bash
ads      29930  0.2  1.0 18188 5376 ?        S    11:38   0:28 gnome-system-monitor
root     30546  0.0  0.1  1908  684 ?        S    13:19   0:00 pppd 230400 -detach crtscts defaultroute usepeerdns user xxxxxxxx@worldnet.att.net
ads      30657  0.0  0.3  5312 1844 ?        S    13:52   0:00 oafd --ac-activate --ior-output-fd=12
ads      30881  0.0  0.1  2696  756 pts/0    R    14:46   0:00 ps aux
-------------- next part --------------
[ads@ADS1 examples]$ idle
IDLE socket error: Address already in use, retrying...
IDLE socket error: Address already in use, retrying...
IDLE socket error: Address already in use, retrying...
 
IDLE cannot run.
 
IDLE needs to use a specific TCP/IP port (8833) in order to communicate with
its Python execution server.  IDLE is unable to bind to this port, and so
cannot start. Here are some possible causes of this problem:
 
  1. TCP/IP networking is not installed or not working on this computer
  2. Another program (another IDLE?) is running that uses this port
  3. Personal firewall software is preventing IDLE from using this port
 
Run IDLE with the -n command line switch to start without a subprocess
and refer to Help/IDLE Help "Running without a subprocess" for further
details.
From neal at metaslash.com  Thu Feb 26 16:10:49 2004
From: neal at metaslash.com (Neal Norwitz)
Date: Thu Feb 26 16:17:17 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
In-Reply-To: <1077825054.13728.312.camel@ADS1>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain>
	<1077825054.13728.312.camel@ADS1>
Message-ID: <20040226211048.GO21005@epoch.metaslash.com>

On Thu, Feb 26, 2004 at 02:50:54PM -0500, Al Schapira wrote:
> Thanks, Kurt,
> 
> I did try to kill all python processes, but that did not help.  Of
> course, shutting down and restarting linux cleared the port, as
> expected.
> 
> Subsequently, idle had been working okay through many sequential
> invokations, until just now!
> I have attached the error output and ps aux output as requested.

>From ps alone, it's not possible to tell what process has the port.
On linux you can do this: 

        netstat -atnp

You will probably need to be root to run this command and get
meaningful results.  Otherwise, netstat will only print processes
you own.

Neal

From a.d.schapira at worldnet.att.net  Thu Feb 26 16:27:50 2004
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Thu Feb 26 16:25:22 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833
	w/python 2.3.3
In-Reply-To: <1077830687.13728.316.camel@ADS1>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain> <1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
Message-ID: <1077830870.13728.318.camel@ADS1>

Port 8833 IS there. I missed it because it was near the top.  :-)
	-Al

On Thu, 2004-02-26 at 16:24, Al Schapira wrote:
> Thanks Neal,
> Attached is the output of netstat -atnp (as root) but I don't see 8833
> there.  Idle still fails to bind to 8833 as before.
> 	-Al
> 
> On Thu, 2004-02-26 at 16:10, Neal Norwitz wrote:
> > On Thu, Feb 26, 2004 at 02:50:54PM -0500, Al Schapira wrote:
> > > Thanks, Kurt,
> > > 
> > > I did try to kill all python processes, but that did not help.  Of
> > > course, shutting down and restarting linux cleared the port, as
> > > expected.
> > > 
> > > Subsequently, idle had been working okay through many sequential
> > > invokations, until just now!
> > > I have attached the error output and ps aux output as requested.
> > 
> > >From ps alone, it's not possible to tell what process has the port.
> > On linux you can do this: 
> > 
> >         netstat -atnp
> > 
> > You will probably need to be root to run this command and get
> > meaningful results.  Otherwise, netstat will only print processes
> > you own.
> > 
> > Neal


From a.d.schapira at worldnet.att.net  Thu Feb 26 16:24:47 2004
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Thu Feb 26 16:31:01 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833
	w/python 2.3.3
In-Reply-To: <20040226211048.GO21005@epoch.metaslash.com>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain> <1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
Message-ID: <1077830687.13728.316.camel@ADS1>

Thanks Neal,
Attached is the output of netstat -atnp (as root) but I don't see 8833
there.  Idle still fails to bind to 8833 as before.
	-Al

On Thu, 2004-02-26 at 16:10, Neal Norwitz wrote:
> On Thu, Feb 26, 2004 at 02:50:54PM -0500, Al Schapira wrote:
> > Thanks, Kurt,
> > 
> > I did try to kill all python processes, but that did not help.  Of
> > course, shutting down and restarting linux cleared the port, as
> > expected.
> > 
> > Subsequently, idle had been working okay through many sequential
> > invokations, until just now!
> > I have attached the error output and ps aux output as requested.
> 
> >From ps alone, it's not possible to tell what process has the port.
> On linux you can do this: 
> 
>         netstat -atnp
> 
> You will probably need to be root to run this command and get
> meaningful results.  Otherwise, netstat will only print processes
> you own.
> 
> Neal
-------------- next part --------------
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 0.0.0.0:32768           0.0.0.0:*               LISTEN      660/rpc.statd       
tcp        0      0 127.0.0.1:8833          0.0.0.0:*               LISTEN      30657/oafd          
tcp        0      0 127.0.0.1:32769         0.0.0.0:*               LISTEN      791/xinetd          
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1008/smbd           
tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN      836/spamd -d -c -a  
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      641/portmap         
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      1126/X              
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      777/sshd            
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      877/cupsd           
tcp        0      0 0.0.0.0:505             0.0.0.0:*               LISTEN      1039/rcd            
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      817/sendmail: accep 
tcp        0      0 127.0.0.1:47070         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47071         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47069         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47074         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47072         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47073         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47077         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47082         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47081         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47086         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47084         127.0.0.1:631           TIME_WAIT   -                   
tcp        0      0 127.0.0.1:47085         127.0.0.1:631           TIME_WAIT   -                   
tcp        1      0 127.0.0.1:8833          127.0.0.1:45050         CLOSE_WAIT  30657/oafd          
tcp        0      0 12.75.181.206:47076     65.197.236.51:80        ESTABLISHED 13842/mozilla-bin   
tcp        0    998 12.75.181.206:47078     65.197.236.51:80        ESTABLISHED 13842/mozilla-bin   
tcp        0    958 12.75.181.206:47083     65.197.236.51:80        ESTABLISHED 13842/mozilla-bin   
tcp        1      0 127.0.0.1:36347         127.0.0.1:631           CLOSE_WAIT  13728/evolution     
tcp        1      0 127.0.0.1:36349         127.0.0.1:631           CLOSE_WAIT  13728/evolution     
tcp        0      0 12.75.181.206:47079     65.197.236.62:80        ESTABLISHED 13842/mozilla-bin   
From neal at metaslash.com  Thu Feb 26 16:45:06 2004
From: neal at metaslash.com (Neal Norwitz)
Date: Thu Feb 26 16:45:36 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
In-Reply-To: <1077830687.13728.316.camel@ADS1>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain>
	<1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
Message-ID: <20040226214506.GR21005@epoch.metaslash.com>

On Thu, Feb 26, 2004 at 04:24:47PM -0500, Al Schapira wrote:
> Thanks Neal,
> Attached is the output of netstat -atnp (as root) but I don't see 8833
> there.  Idle still fails to bind to 8833 as before.

> Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
> tcp        0      0 127.0.0.1:8833          0.0.0.0:*               LISTEN      30657/oafd          

You should be able to kill 30657 (or kill `pidof oafd`) which is the
GNOME Object Activation Daemon.  I believe this is restarted
automatically if you are still running GNOME.  Just to be safe, you
can do a ps auxww | grep oafd before killing it, so you can restart it
manually if necessary.

Neal

From a.d.schapira at worldnet.att.net  Thu Feb 26 17:01:05 2004
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Thu Feb 26 16:58:41 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833
	w/python 2.3.3
In-Reply-To: <20040226214506.GR21005@epoch.metaslash.com>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain> <1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
	<20040226214506.GR21005@epoch.metaslash.com>
Message-ID: <1077832865.13728.326.camel@ADS1>

Neal,
Yes, killing oafd enabled idle to start with subprocesses.
This is what was running:

 oafd --ac-activate --ior-output-fd=12

It did not restart.  Based on the man page, its for CORBA, Orbit, OAF
and/or Bonobo.  Since I don't know what any of those are, I'm not sure I
need it.  Can you elaborate?

Does killing oafd shed any light on what the problem with idle really
is?

Thanks,
	-Al
  

On Thu, 2004-02-26 at 16:45, Neal Norwitz wrote:
> On Thu, Feb 26, 2004 at 04:24:47PM -0500, Al Schapira wrote:
> > Thanks Neal,
> > Attached is the output of netstat -atnp (as root) but I don't see 8833
> > there.  Idle still fails to bind to 8833 as before.
> 
> > Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
> > tcp        0      0 127.0.0.1:8833          0.0.0.0:*               LISTEN      30657/oafd          
> 
> You should be able to kill 30657 (or kill `pidof oafd`) which is the
> GNOME Object Activation Daemon.  I believe this is restarted
> automatically if you are still running GNOME.  Just to be safe, you
> can do a ps auxww | grep oafd before killing it, so you can restart it
> manually if necessary.
> 
> Neal


From neal at metaslash.com  Thu Feb 26 17:17:00 2004
From: neal at metaslash.com (Neal Norwitz)
Date: Thu Feb 26 17:17:05 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
In-Reply-To: <1077832865.13728.326.camel@ADS1>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain>
	<1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
	<20040226214506.GR21005@epoch.metaslash.com>
	<1077832865.13728.326.camel@ADS1>
Message-ID: <20040226221700.GU21005@epoch.metaslash.com>

On Thu, Feb 26, 2004 at 05:01:05PM -0500, Al Schapira wrote:
> Neal,
> Yes, killing oafd enabled idle to start with subprocesses.
> This is what was running:
> 
>  oafd --ac-activate --ior-output-fd=12
> 
> It did not restart.  Based on the man page, its for CORBA, Orbit, OAF
> and/or Bonobo.  Since I don't know what any of those are, I'm not sure I
> need it.  Can you elaborate?

I'll try to describe in a general way that isn't exact:

        This is your windowing (graphical) system (GNOME or Bonobo).
        It allows GNOME applications to talk a common language (CORBA).

        Strickly speaking it isn't necessary, unless/until some
        applications need to communicate, e.g., when you make
        a configuration change to the window manager.

> Does killing oafd shed any light on what the problem with idle really
> is?

You can restart the process if you wish.  IIRC, it's started when
necessary.  The problem doesn't haven anything to do with IDLE
specifically.  When you started X (perhaps by logging in),
GNOME started up, which started oafd and it took port 8833.
Unfortunately, IDLE is hard coded (IIRC) to use the same port.
So there is a conflict since each program is trying to use
the same port.  Whichever starts first wins.  I think oafd
can use any port.  

Just in case, you can verify that 8833 is not in /etc/services.
If it is in there, change the value to another number.  The
new number must be unique in /etc/services (at least for all
the TCP services).

HTH,
Neal

From kbk at shore.net  Thu Feb 26 18:13:57 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu Feb 26 18:14:11 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
In-Reply-To: <20040226221700.GU21005@epoch.metaslash.com> (Neal Norwitz's
	message of "Thu, 26 Feb 2004 17:17:00 -0500")
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain> <1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
	<20040226214506.GR21005@epoch.metaslash.com>
	<1077832865.13728.326.camel@ADS1>
	<20040226221700.GU21005@epoch.metaslash.com>
Message-ID: <87ekshbfii.fsf@hydra.localdomain>

Neal Norwitz <neal@metaslash.com> writes:

> You can restart the process if you wish.  IIRC, it's started when
> necessary.  The problem doesn't haven anything to do with IDLE
> specifically.  When you started X (perhaps by logging in),
> GNOME started up, which started oafd and it took port 8833.
> Unfortunately, IDLE is hard coded (IIRC) to use the same port.
> So there is a conflict since each program is trying to use
> the same port.  Whichever starts first wins.  I think oafd
> can use any port.  

It's strange it would use 8833 twice, but I guess system startup is
deterministic.  I looked around a bit, but Bonobo is complex, and I
ran out of time trying to figure out whether oasd's port is hard
coded.

> Just in case, you can verify that 8833 is not in /etc/services.
> If it is in there, change the value to another number.  The
> new number must be unique in /etc/services (at least for all
> the TCP services).

If IDLE's port was registered in /etc/services, might that
prevent oasd from grabbing it?  Or is services just advisory?

In any case, IDLE is indeed hard coded to 8833.  That's in
PyShell.py:ModifiedInterpreter(), around line 322.  There should be no
problem changing it to, say, 8843 if that solves the problem.  Just
run IDLE as root with the -n switch, load the PyShell module, change that
line, and try again.

In the future, IDLE will find another port if one is in use.  That
will pave the way for running multiple IDLEs, and also fix this
problem.

-- 
KBK

From a.d.schapira at worldnet.att.net  Thu Feb 26 18:25:08 2004
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Thu Feb 26 18:22:58 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833
	w/python 2.3.3
In-Reply-To: <20040226221700.GU21005@epoch.metaslash.com>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain> <1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
	<20040226214506.GR21005@epoch.metaslash.com>
	<1077832865.13728.326.camel@ADS1>
	<20040226221700.GU21005@epoch.metaslash.com>
Message-ID: <1077836784.13728.365.camel@ADS1>

On Thu, 2004-02-26 at 17:17, Neal Norwitz wrote:

> I'll try to describe in a general way that isn't exact:
> 
>         This is your windowing (graphical) system (GNOME or Bonobo).
>         It allows GNOME applications to talk a common language (CORBA).
> 
>         Strickly speaking it isn't necessary, unless/until some
>         applications need to communicate, e.g., when you make
>         a configuration change to the window manager.

Thanks.  This explanation does help.

> 
> > Does killing oafd shed any light on what the problem with idle really
> > is?
> 
> You can restart the process if you wish.  IIRC, it's started when
> necessary.  The problem doesn't haven anything to do with IDLE
> specifically.  When you started X (perhaps by logging in),
> GNOME started up, which started oafd and it took port 8833.
> Unfortunately, IDLE is hard coded (IIRC) to use the same port.

Shall I file a bug report (enhancement request) for idle to use another
port if 8833 is busy?

> So there is a conflict since each program is trying to use
> the same port.  Whichever starts first wins.  I think oafd
> can use any port.  

This would explain things except for fact that idle was working fine in
subprocess mode for many invocations before it failed.  Perhaps oafd
started up in between two idle runs.
> 
> Just in case, you can verify that 8833 is not in /etc/services.
> If it is in there, change the value to another number.  The
> new number must be unique in /etc/services (at least for all
> the TCP services).

"grep -rs 8833 /etc" yielded no relevant matches.  Where else should I
look? I do not have an /etc/services file or directory. (RH 9)

> 
> HTH,
> Neal

Thanks again.
	-Al



From ibksapjgkbdd at yahoo.com  Fri Feb 27 15:33:49 2004
From: ibksapjgkbdd at yahoo.com (willa boym)
Date: Fri Feb 27 15:34:59 2004
Subject: [Idle-dev] A joke? How about your secks lifeengallado
Message-ID: <VEKEHBFQXDJPVNDKOASEIBE@yahoo.com>

An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20040228/7fb4bbfd/attachment.html
From neal at metaslash.com  Fri Feb 27 16:37:15 2004
From: neal at metaslash.com (Neal Norwitz)
Date: Fri Feb 27 16:37:20 2004
Subject: [Idle-dev] idle 1.0.2 cannot bind (again) to port 8833 w/python
	2.3.3
In-Reply-To: <87ekshbfii.fsf@hydra.localdomain>
References: <403A53C8.70203@worldnet.att.net>
	<87d682euqo.fsf@hydra.localdomain>
	<1077825054.13728.312.camel@ADS1>
	<20040226211048.GO21005@epoch.metaslash.com>
	<1077830687.13728.316.camel@ADS1>
	<20040226214506.GR21005@epoch.metaslash.com>
	<1077832865.13728.326.camel@ADS1>
	<20040226221700.GU21005@epoch.metaslash.com>
	<87ekshbfii.fsf@hydra.localdomain>
Message-ID: <20040227213715.GS21005@epoch.metaslash.com>

On Thu, Feb 26, 2004 at 06:13:57PM -0500, Kurt B. Kaiser wrote:
> 
> > Just in case, you can verify that 8833 is not in /etc/services.
> > If it is in there, change the value to another number.  The
> > new number must be unique in /etc/services (at least for all
> > the TCP services).
> 
> If IDLE's port was registered in /etc/services, might that
> prevent oasd from grabbing it?  Or is services just advisory?

No, but it would allow the port IDLE uses to be changed without
modifying any code.  It would also document what port IDLE uses.
The only reason to make a port in /etc/services unique is to
ensure there isn't a conflict if both programs are run
simultaneously

/etc/services really just provides a mapping from name to number.
It allows a user to change the actual port in the case there's
a conflict.

Neal