From jpsc@users.sourceforge.net Tue Dec 5 16:38:49 2000 From: jpsc@users.sourceforge.net (JP S-C) Date: Tue, 5 Dec 2000 08:38:49 -0800 (PST) Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE Message-ID: <20001205163849.26792.qmail@web2205.mail.yahoo.com> Dear ILDE-dev and IDLE fork, Is anyone interested in making Python's whitespace (tabs) more speech-friendly under IDLE? I sent an e-mail to Meta-SIG proposing that an Access-SIG be created and a few people suggested it would be more fitting for IDLE than a SIG. I run a free software project named Ocularis (http://ocularis.sourceforge.net) that has the goal of making Linux more accessible. We currently do a lot of programming Python, so we really want to make Python more accessible, especially for the visually impaired. Any thoughts or interests? Thanks. --JP Schnapper-Casteras jpsc@users.sourceforge.net __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From dscherer@cmu.edu Tue Dec 5 17:46:23 2000 From: dscherer@cmu.edu (David Scherer) Date: Tue, 5 Dec 2000 12:46:23 -0500 Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: <20001205163849.26792.qmail@web2205.mail.yahoo.com> Message-ID: > Is anyone interested in making Python's > whitespace (tabs) more speech-friendly under IDLE? How would this be done? I don't know anything about the conventions used for such things. if x<>y: if x<3: x = x + 1 x = x + y Saying each tab character where it appears gives: "if x not equal y colon; tab if x less than 3 colon; tab tab x equals x plus 1; tab x equals x plus y" Saying the invisible DEDENT tokens gives: "if x not equal y colon; if x less than 3 colon; x equals x plus 1; dedent; x equals x plus y; dedent" Or, equivalently you could invent an "end if": "if x not equal y colon; if x less than 3 colon; x equals x plus 1; end if; x equals x plus y; end if" How about using pitch? My background in music theory is limited to having played the piano when I was six, but something like: (C3)"if x not equal y colon" (E3)"if x less than 3 colon" (G3)"x equals x plus 1" (E3)"x equals x plus y" Any other ideas? I don't think I will have time to work on this, but I can kibitz ;) Dave From glyph@twistedmatrix.com Tue Dec 5 18:48:56 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 5 Dec 2000 13:48:56 -0500 (EST) Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: Message-ID: On Tue, 5 Dec 2000, David Scherer wrote: > How about using pitch? My background in music theory is limited to having > played the piano when I was six, but something like: > > (C3)"if x not equal y colon" > (E3)"if x less than 3 colon" > (G3)"x equals x plus 1" > (E3)"x equals x plus y" My head is now filled with visions of thousands of python programmers singing their code slightly off key. "(G3) quote quote quote Look on the bright side of life quote quote quote" ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ From tim.one@home.com Wed Dec 6 22:25:20 2000 From: tim.one@home.com (Tim Peters) Date: Wed, 6 Dec 2000 17:25:20 -0500 Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: Message-ID: [JP S-C] > Is anyone interested in making Python's > whitespace (tabs) more speech-friendly under IDLE? [David Scherer] > How would this be done? I'm not clear on what JP has in mind either. > I don't know anything about the conventions used for such things. > > if x<>y: > if x<3: > x = x + 1 > x = x + y > > Saying each tab character where it appears gives: > > "if x not equal y colon; tab if x less than 3 colon; tab tab x > equals x plus 1; tab x equals x plus y" > > Saying the invisible DEDENT tokens gives: > ... Programming by speech is difficult, because variable and module names are rarely chosen for ease of pronunciation (pyclbr.py), many aren't real words at all (== they're unlikely to be found in a recognition engine's database of word pronunciations), and there's a weak "language model" (only part of speech recog is acoustic recognition; the rest has to make sense of context, as in "Please write a letter to Mrs. Wright right away, please": there are 3 homonyms of "write" in that sentence, and only context can determine which was intended in each place). So it's a tough problem, and block structure seems the least of it. Suggest if x not equal y open-block if x less than 3 open-block x equals x plus 1 close-block # how to know "one" wasn't intended? x equals x plus y close-block # how to know "why" wasn't intended? The phrases "open-block" and "close-block" are not confusable via acoustics (they're better this way than, say, "indent" and "dedent"), and could be treated like keystroke macros (open-block -> colon then newline (IDLE will indent by itself given those keys); close-block -> newline then backspace, although IDLE will invent the backspace by itself sometimes (e.g., after a "return" stmt), so the IDLE parser should communicate with the speech module to do what's intended rather than what's said ). > ... > How about using pitch? A few years ago, a blind fellow on comp.lang.python reported using pitch in a text-to-speech add-on to the Emacs python-mode, to help him understand when indentation changed in Python code. It's important to remember that people are very good at mining info out of *any* system of clues, no matter how odd they may seem at first, provided they're consistent. I've heard that some people can even make sense out of Perl code . From jp_sc@yahoo.com Wed Dec 6 06:24:15 2000 From: jp_sc@yahoo.com (JP S-C) Date: Tue, 05 Dec 2000 22:24:15 -0800 Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE References: Message-ID: <3A2DDB8F.3CC2AFDA@yahoo.com> > How would this be done? I don't know anything about the conventions used > for such things. There aren't really any, that's part of the problem :-) > if x<>y: > if x<3: > x = x + 1 > x = x + y > > Saying each tab character where it appears gives: > > "if x not equal y colon; tab if x less than 3 colon; tab tab x equals x plus > 1; tab x equals x plus y" That's what I was envisioning as easiest and perhaps best solution. > How about using pitch? My background in music theory is limited to having > played the piano when I was six, but something like: > > (C3)"if x not equal y colon" > (E3)"if x less than 3 colon" > (G3)"x equals x plus 1" > (E3)"x equals x plus y" What a cool idea. I'd never thought of that. How well would it work for the non-musical or those who have never played an instrument? > Any other ideas? I don't think I will have time to work on this, but I can > kibitz ;) Kibitz away! :-] --JP _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From DavidA@ActiveState.com Thu Dec 7 05:20:22 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 6 Dec 2000 21:20:22 -0800 (Pacific Standard Time) Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: <3A2DDB8F.3CC2AFDA@yahoo.com> Message-ID: A few months back, after a scary bout with wrist pains, I spent a fair bit of time thinking about how to code in Python w/o being bound to the keyboard. For what it's worth, I think that the answer lies in breaking the whole serial token metaphors, and to think about coding at a higher level of actions, such as "define a class", "define a function", "define a method", "write a switch statement" (yes, I know there aren't any in Python _syntax_, that doesn't mean people don't write them), etc. My lazy experiments with speech recognition didn't prove very successful, and my hands are still usable, even if more fragile, so I wasn't limited to speech input; I was also programming on hand-helds at the time, so I focused more of my day-dreaming on coarse motor control UIs complemented with custom visual UI elements. I 'noticed' that one of the nice things about Python (from a UI perspective) is that the branching factor is quite low at any given context of a program, with some branches having much higher probabilities of being what the programmer needs than others. For example, inside a class, the 'define-method' branch has a high likelihood of being the correct branch to take, as opposed to an if-statement or a looping construct. There are UI elements such as pie chart controls which researchers have shown to be quite successful 'choosing' mechanisms. Giving those a Bayesian flavor either by changing the slice widths or by organizing the order of the choices around the pie could make the "most common path" a very easily input one. I could go on like that for a long time, but that's probably useless as I'm unable to commit the time it would take to expand these ideas. I just wanted to suggest that people think a little outside the box, and examine the properties of the language. The proposals I've seen on the list so far could apply just as well to Perl as to Python, but the two languages are fundamentally different and should be spoken differently =). What I will do is volunteer to organize a get-together at IPC9 on the topic, as long as it's over some drinks. I'm pretty sure we can get a couple of speech-recognition experts to partake. =) --david ascher PS: Hopefully I'll be able to implement some of these ideas in a future version of Komodo. =) From jpsc@users.sourceforge.net Thu Dec 7 07:57:25 2000 From: jpsc@users.sourceforge.net (JP S-C) Date: Wed, 6 Dec 2000 23:57:25 -0800 (PST) Subject: [Idle-Dev] Making Python Speech-Friendly Under IDLE Message-ID: <20001207075725.28846.qmail@web2203.mail.yahoo.com> On Wed, 06 Dec 2000, David Ascher wrote: > A few months back, after a scary bout with wrist > pains, I spent a fair bit of time thinking about how > to code in Python w/o being bound to the keyboard. > For what it's worth, I think that the answer lies in > breaking the whole serial token metaphors, and to > think about coding at a higher level of actions, such > as "define a class", "define a function", "define a > method", ... > My lazy experiments with speech recognition didn't > prove very successful, and my hands are still usable, > even if more fragile, so I wasn't limited to speech > input; I'm glad your wrist pains ceased or diminished. > I 'noticed' that one of the nice things > about Python (from a UI perspective) is that the > branching factor is quite low at any given context of > a program, with some branches having much > higher probabilities of being what the programmer > needs than others. For example, inside a class, the > 'define-method' branch has a high likelihood of being > the correct branch to take, as opposed to an > if-statement or a looping construct. Very interesting. You seem to be describing two ideas: one about programming by speech and another about minimizing human computer interaction. VoiceCode (http://sourceforge.net/projects/voicecode) is working on the first idea: "VoiceCode is an Open Source initiative started by the National Research Council of Canada, to develop a programming by voice toolbox. The aim of the project is to make programming through voice input as easy and productive as with mouse and keyboard." Source: http://sourceforge.net/projects/voicecode I talked to someone from VoiceCode a while ago and they seemed to be concentrating on developing basic features (e.g., support for different languages). Eventually, it would be nice if VoiceCode could be integrated with text-to-speech software to make a hands free, eyes free, and theoretically, ears free IDE. I think the second idea about minimizing human computer interaction is the one we should focus on and discuss further. There are a huge number of applications for what you have described, including newbie/intermediate programming and any environment that wants to maximize a user's efficiency (especially a user who is not using a mouse, keyboard, or possibly a monitor). > I could go on like that for a long time, but that's > probably useless as I'm unable to commit the time it > would take to expand these ideas. I just wanted to > suggest that people think a little outside the box, > and examine the properties of the language. Thank you, that's always a good suggestion. > The proposals I've seen on the > list so far could apply just as well to Perl as to > Python, but the two languages are fundamentally > different and should be spoken differently =). True, although I think basic "tab", "indent", "dedent", "x number spaces" would work decently for both. > What I will do is volunteer to organize a > get-together at IPC9 on the topic, as long as it's > over some drinks. I'm pretty sure we can get > a couple of speech-recognition experts to partake. =) That would be nice. I am not currently planning to attend IPC9, but I'll check. If most of you live in California or are interested, our project (Project Ocularis) is going to be having an event in L.A. in late March. Thanks for your well thought out comments. Talk to you soon. --JP __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From jpsc@users.sourceforge.net Thu Dec 7 06:54:03 2000 From: jpsc@users.sourceforge.net (JP S-C) Date: Wed, 6 Dec 2000 22:54:03 -0800 Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: References: Message-ID: <00120623171000.00700@localhost.localdomain> On Wed, 06 Dec 2000, David Ascher wrote: > For what it's worth, I think that the answer lies in breaking > the whole serial token metaphors, and to think about coding at a higher > level of actions, such as "define a class", "define a function", "define a > method" ... > My lazy experiments with speech recognition didn't prove very successful, > and my hands are still usable, even if more fragile, so I wasn't limited > to speech input; I'm glad that your wrists pains ceased. > I 'noticed' that one of the nice things > about Python (from a UI perspective) is that the branching factor is quite > low at any given context of a program, with some branches having much > higher probabilities of being what the programmer needs than others. For > example, inside a class, the 'define-method' branch has a high likelihood > of being the correct branch to take, as opposed to an if-statement or a > looping construct. Very interesting. It seems like what you are saying fits in to two categories: one about coding by speech and one about coding effectively if you cannot see or use the keyboard. The first, coding by speech, is somewhat out our (Project Ocularis') league in terms of the time needed to obtain adequate speech-to-text results. However, there is a project called VoiceCode (http://sourceforge.net/projects/VoiceCode/) that does deal with this. "VoiceCode is an Open Source initiative started by the National Research Council of Canada, to develop a programming by voice toolbox. The aim of the project is to make programming through voice input as easy and productive as with mouse and keyboard." Source: http://sourceforge.net/projects/VoiceCode/ I talked to someone from VoiceCode a while ago and they seemed to be focusing on developing speech-to-text and basic features/functions before integrating their software with for the visually impaired. Eventually, this would be really cool, since it would be a hands and eyes free (theoretically ears free) method of programming. The second idea, coding effectively but non-visually or without a keyboard or mouse. It seems this has a huge number of applications, including newbie/intermediate coding and any time when human computer interaction should be minimized (e.g., hands free, eyes free, etc.). I think this might be the idea we should focus on in our discussions (after talking about or implementing basic options like piping the word "tab" or "indent" and then "dedent" to your speech synthesizer of choice). > I could go on like that for a long time, but that's probably useless > as I'm unable to commit the time it would take to expand these ideas. I > just wanted to suggest that people think a little outside the box, and > examine the properties of the language. Thank you, that's always a good suggestion. > The proposals I've seen on the > list so far could apply just as well to Perl as to Python, but the two > languages are fundamentally different and should be spoken differently =). :-) True. Basic "tab", "indent", "dedent" or "x number of spaces" would work for both, although Perl has no equivalent to IDLE (good for us!) > What I will do is volunteer to organize a get-together at IPC9 on the > topic, as long as it's over some drinks. I'm pretty sure we can get a > couple of speech-recognition experts to partake. =) =-) Oh, that would be nice. I'm not currently planning to go to IPC9, I'll have to check on that. If most of you are in California or if you are interested, our project is having an event in L.A. in late March. Thanks for sharing your ideas and experience. Talk to you later. --JP __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From jpsc@users.sourceforge.net Thu Dec 7 07:35:16 2000 From: jpsc@users.sourceforge.net (JP S-C) Date: Wed, 6 Dec 2000 23:35:16 -0800 Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: References: Message-ID: <00120623551600.00890@localhost.localdomain> On Wed, 06 Dec 2000, David Ascher wrote: > A few months back, after a scary bout with wrist pains, I spent a fair bit > of time thinking about how to code in Python w/o being bound to the > keyboard. For what it's worth, I think that the answer lies in breaking > the whole serial token metaphors, and to think about coding at a higher > level of actions, such as "define a class", "define a function", "define a > method", ... > My lazy experiments with speech recognition didn't prove very successful, > and my hands are still usable, even if more fragile, so I wasn't limited > to speech input; I'm glad your wrist pains ceased or diminished. > I 'noticed' that one of the nice things > about Python (from a UI perspective) is that the branching factor is quite > low at any given context of a program, with some branches having much > higher probabilities of being what the programmer needs than others. For > example, inside a class, the 'define-method' branch has a high likelihood > of being the correct branch to take, as opposed to an if-statement or a > looping construct. Very interesting. You seem to be describing two ideas: one about programming by speech and another about minimizing human computer interaction. VoiceCode (http://sourceforge.net/projects/voicecode) is working on the first idea: "VoiceCode is an Open Source initiative started by the National Research Council of Canada, to develop a programming by voice toolbox. The aim of the project is to make programming through voice input as easy and productive as with mouse and keyboard." Source: http://sourceforge.net/projects/voicecode I talked to someone from VoiceCode a while ago and they seemed to be concentrating on developing basic features (e.g., support for different languages). Eventually, it would be nice if VoiceCode could be integrated with text-to-speech software to make a hands free, eyes free, and theoretically, ears free IDE. I think the second idea about minimizing human computer interaction is the one we should focus on and discuss further. There are a huge number of applications for what you have described, including newbie/intermediate programming and any environment that wants to maximize a user's efficiency (especially a user who is not using a mouse, keyboard, or possibly a monitor). > I could go on like that for a long time, but that's probably useless > as I'm unable to commit the time it would take to expand these ideas. I > just wanted to suggest that people think a little outside the box, and > examine the properties of the language. The proposals I've seen on the > list so far could apply just as well to Perl as to Python, but the two > languages are fundamentally different and should be spoken differently =). > > What I will do is volunteer to organize a get-together at IPC9 on the > topic, as long as it's over some drinks. I'm pretty sure we can get a > couple of speech-recognition experts to partake. =) > > --david ascher > > PS: Hopefully I'll be able to implement some of these ideas in a future > version of Komodo. =) __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From dscherer@milliway.kssacct.com Thu Dec 7 14:17:22 2000 From: dscherer@milliway.kssacct.com (David Scherer) Date: Thu, 7 Dec 2000 14:17:22 +0000 (GMT) Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: <3A2DDB8F.3CC2AFDA@yahoo.com> Message-ID: > > "if x not equal y colon; tab if x less than 3 colon; tab tab x equals x plus > > 1; tab x equals x plus y" > > That's what I was envisioning as easiest and perhaps best solution. The problem is that, unlike in "visual" programming, you are required to remember the current indentation level, which takes up one *very* precious short-term memory slot and adds an opportunity for misinterpretation. It might also be hard to reliably tell the difference between, say, "tab tab tab tab" and "tab tab tab tab tab". I think Tim's "open-block" and "close-block" would be better, however we spell them. It's possible to interpret block structure without knowing the absolute indentation level, e.g. void main() { short x; if (x>0) { while (x) { x = x-1; } } } Indentation is better than this precisely because it's a visual effect that clearly groups statements together without interfering with their meaning or requiring you to keep extra information in your head. The only analogous thing I can think of in the audio domain is pitch. > What a cool idea. I'd never thought of that. How well would it work > for the non-musical or those who have never played an instrument? If it works at all, I doubt it would depend on musical talent. Remember, the *key* point is that you can recognize indents and dedents, which would be changes in pitch up and down, respectively. If you have a speech synthesizer that can vary its pitch in response to control commands of some kind, you could test the effect by coding samples of Python by hand. If you don't have such a synthesizer, that's an obvious technical obstacle to implementing this idea :) Dave From jpsc@users.sourceforge.net Thu Dec 7 20:52:26 2000 From: jpsc@users.sourceforge.net (JP S-C) Date: Thu, 7 Dec 2000 12:52:26 -0800 (PST) Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE Message-ID: <20001207205226.29539.qmail@web2205.mail.yahoo.com> -- David Scherer wrote: > It might also be hard to reliably tell the > difference between, say, "tab tab tab tab" and "tab > tab tab tab tab". True. What about saying "x number of tabs"? > Indentation is better than this precisely because > it's a visual effect that clearly groups statements > together without interfering with their meaning or > requiring you to keep extra information in your > head. The only analogous thing I can think of in > the audio domain is pitch. > If it works at all, I doubt it would depend on > musical talent. Remember, the *key* point is that > you can recognize indents and dedents, which would > be changes in pitch up and down, respectively. The more I think about it, the more convinced I am that it might work well, even for the non-musically-oriented. The changes in pitch would have to be big enough to be distinguishable. Could there be a problem with having so many indents that the raise in pitch would go past the audible range? This would be pretty far-fetched, but I would think it would be nice to have simple feature that read "x number of indents" if x > 10 or something. > If you have a speech synthesizer that can vary its > pitch in response to control commands of some kind, > you could test the effect by coding samples > of Python by hand. If you don't have such a > synthesizer, that's an obvious technical obstacle to > implementing this idea :) :-) Yeah, that would be a problem. Changing the pitch of speech spoken by a software synthesizer is very specific to the synthesizer you are using and it would be a lot of work to add support for the common ones. (On another note, that's why we're trying to create some standard interface.) Best Regards, --JP __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From jpsc@users.sourceforge.net Thu Dec 7 21:06:25 2000 From: jpsc@users.sourceforge.net (JP S-C) Date: Thu, 7 Dec 2000 13:06:25 -0800 (PST) Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE Message-ID: <20001207210625.20315.qmail@web2202.mail.yahoo.com> > So it's a tough problem, and block structure seems > the least of it. True. > Suggest > > if x not equal y open-block > if x less than 3 open-block > x equals x plus 1 close-block # how to know "one" > # wasn't intended? > x equals x plus y close-block # how to know "why" > # wasn't intended? > > The phrases "open-block" and "close-block" are not > confusable via acoustics (they're better this way > than, say, "indent" and "dedent"), and could > be treated like keystroke macros (open-block -> > colon then newline (IDLE will indent by itself given > those keys); close-block -> newline then backspace, > although IDLE will invent the backspace by itself > sometimes (e.g., after a "return" stmt), I think this would work really well for input. I am debating over what would be better for output: modulating pitch according to indents or dedents or using a similar macro to turn tabs back into "open-block" and "close-block" and speak them. > It's important to remember that people are very good > at mining info out of *any* system of clues, no > matter how odd they may seem at first, provided > they're consistent. True. > I've heard that some people can even make sense out > of Perl code . :-) Ha, Let's not go there. Best Regards, --JP __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From mats@laplaza.org Fri Dec 8 12:41:31 2000 From: mats@laplaza.org (Mats Wichmann) Date: Fri, 08 Dec 2000 07:41:31 -0500 Subject: [Idle-dev] Making Python Speech-Friendly Under IDLE In-Reply-To: References: <3A2DDB8F.3CC2AFDA@yahoo.com> Message-ID: <5.0.0.25.1.20001208073612.00a90a40@mail.laplaza.org> >> What a cool idea. I'd never thought of that. How well would it work >> for the non-musical or those who have never played an instrument? > >If it works at all, I doubt it would depend on musical talent. Remember, >the *key* point is that you can recognize indents and dedents, which would >be changes in pitch up and down, respectively. > >If you have a speech synthesizer that can vary its pitch in response to >control commands of some kind, you could test the effect by coding samples >of Python by hand. If you don't have such a synthesizer, that's an >obvious technical obstacle to implementing this idea :) I've been told that most (untrained) humans have a very hard time accurately varying/controlling pitch in speech. I was told this in the context of techniques for keeping an audience's attention: breaking out of a monotone is clearly a good idea but it's far easier for us to do that by varying the /pace/ than the /pitch/, which apparently very few people can do reliably. From mats@laplaza.org Wed Dec 20 14:05:21 2000 From: mats@laplaza.org (Mats Wichmann) Date: Wed, 20 Dec 2000 07:05:21 -0700 Subject: [Idle-dev] IDLE and Jython In-Reply-To: References: Message-ID: <5.0.0.25.1.20001220070144.02db7c80@mail.laplaza.org> Have there been any thoughts on making an IDLE-like beast for Jython? Presumably all the Tk stuff that IDLE uses would have to be replaced with Java (which might be daunting enough), but would there be other issues? From glyph@twistedmatrix.com Wed Dec 20 17:09:53 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 20 Dec 2000 12:09:53 -0500 (EST) Subject: [Idle-dev] IDLE and Jython In-Reply-To: <5.0.0.25.1.20001220070144.02db7c80@mail.laplaza.org> Message-ID: On Wed, 20 Dec 2000, Mats Wichmann wrote: > Have there been any thoughts on making an IDLE-like > beast for Jython? Not that I'm aware of -- feel free to go ahead and do it, though! > Presumably all the Tk stuff that IDLE uses would have to be replaced > with Java (which might be daunting enough), but would there be other > issues? You could try to use the Java bindings to Tk that are floating around on the JPython website. There isn't terribly much abstract, toolkit independant code packaged with IDLE, so if you're going to do it with another toolkit it's probably going to be a different "product". ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ PS: by the way -- the Tk code will have to be replaced with *AWT* or *Swing*, not "Java"... (the confusion between Java's language (which is passable) and Java's standard libarary (which is an unusable piece of trash) is one of those sun-reinforced myths that life hard for developers trying to advocate high-level languages) From mats@laplaza.org Wed Dec 20 17:13:29 2000 From: mats@laplaza.org (Mats Wichmann) Date: Wed, 20 Dec 2000 10:13:29 -0700 Subject: [Idle-dev] IDLE and Jython In-Reply-To: References: <5.0.0.25.1.20001220070144.02db7c80@mail.laplaza.org> Message-ID: <5.0.0.25.1.20001220100859.010031d0@mail.laplaza.org> At 12:09 PM 12/20/2000 -0500, Glyph Lefkowitz wrote: > > >On Wed, 20 Dec 2000, Mats Wichmann wrote: > >> Have there been any thoughts on making an IDLE-like >> beast for Jython? > >Not that I'm aware of -- feel free to go ahead and do it, though! > >> Presumably all the Tk stuff that IDLE uses would have to be replaced >> with Java (which might be daunting enough), but would there be other >> issues? > >You could try to use the Java bindings to Tk that are floating around on >the JPython website. There isn't terribly much abstract, toolkit >independant code packaged with IDLE, so if you're going to do it with >another toolkit it's probably going to be a different "product". Hmmm, I'd missed that. If I can manage any time at all I'll at least take a look. My frustration at beginning to play with Jython as a way to inspect/test Java classes and /not/ having IDLE available was what led to the question. If there are any other answers to that problem I'd be happy to take a look (I don't speak Emacs, unfortunately, in case that's one). >PS: by the way -- the Tk code will have to be replaced with *AWT* or >*Swing*, not "Java"... (the confusion between Java's language (which is >passable) and Java's standard libarary (which is an unusable piece of >trash) is one of those sun-reinforced myths that life hard for developers >trying to advocate high-level languages) Yes, I know. My apologies for being imprecise... I suspect folks got the gist of it, though. From glyph@twistedmatrix.com Wed Dec 20 18:32:49 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 20 Dec 2000 13:32:49 -0500 (EST) Subject: [Idle-dev] IDLE and Jython In-Reply-To: <5.0.0.25.1.20001220100859.010031d0@mail.laplaza.org> Message-ID: On Wed, 20 Dec 2000, Mats Wichmann wrote: > >You could try to use the Java bindings to Tk that are floating around on > >the JPython website. There isn't terribly much abstract, toolkit > >independant code packaged with IDLE, so if you're going to do it with > >another toolkit it's probably going to be a different "product". > > Hmmm, I'd missed that. If I can manage any time at all I'll at > least take a look. My frustration at beginning to play with > Jython as a way to inspect/test Java classes and /not/ having > IDLE available was what led to the question. If there are any > other answers to that problem I'd be happy to take a look > (I don't speak Emacs, unfortunately, in case that's one). You should learn to speak both Emacs and VI -- they are, respectively, answers to many problems :). (Emacs does not, however, have a python instance inspector.) > >PS: by the way -- the Tk code will have to be replaced with *AWT* or > >*Swing*, not "Java"... (the confusion between Java's language (which is > >passable) and Java's standard libarary (which is an unusable piece of > >trash) is one of those sun-reinforced myths that life hard for developers > >trying to advocate high-level languages) > > > Yes, I know. My apologies for being imprecise... I suspect folks > got the gist of it, though. The reason I mentioned it is because I was wondering what you're planning to use to do your GUI -- since there is a free AWT, but no free Swing. (yet?) ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ From glyph@twistedmatrix.com Wed Dec 20 18:44:46 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 20 Dec 2000 13:44:46 -0500 (EST) Subject: [Idle-dev] IDLE and Jython (fwd) Message-ID: I believe others may find this useful in the context of the discussion: http://jtkinter.sourceforge.net ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ ---------- Forwarded message ---------- Date: Wed, 20 Dec 2000 11:23:05 -0700 From: Mats Wichmann To: Glyph Lefkowitz Subject: Re: [Idle-dev] IDLE and Jython >You could try to use the Java bindings to Tk that are floating around on >the JPython website. Sorry to pester... I can't find this anywhere, and web searches are not useful.... do you happen to have a more precise pointer? Thanks, Mats From fdrake@acm.org Wed Dec 20 18:43:56 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 20 Dec 2000 13:43:56 -0500 (EST) Subject: [Idle-dev] IDLE and Jython In-Reply-To: References: <5.0.0.25.1.20001220100859.010031d0@mail.laplaza.org> Message-ID: <14912.65004.447723.799592@cj42289-a.reston1.va.home.com> Glyph Lefkowitz writes: > The reason I mentioned it is because I was wondering what you're planning > to use to do your GUI -- since there is a free AWT, but no free Swing. My own experience with Swing (early this year) were that it was just dog slow and made the process much bigger than it should have been. This was on a barely-supported system for Sun: Solaris 2.6 on SPARC. The jTkinter page makes it look promising, but I don't have any time to play with Jython these days. -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From glyph@twistedmatrix.com Wed Dec 20 20:00:48 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 20 Dec 2000 15:00:48 -0500 (EST) Subject: [Idle-dev] IDLE and Jython In-Reply-To: <14912.65004.447723.799592@cj42289-a.reston1.va.home.com> Message-ID: *My* experience with swing cannot be adequately described in polite company. It is, to put it mildly, the worst-implemented (and near worst-designed) piece of software I have ever used. However, a good indication of how "well-engineered" it is: under X (presumnably the native engineering environment for Sun people) Swing regularly sends two or more full pixmap copies of the window per redraw thanks to the tremendously clever "double-buffering" scheme which all Swing widgets use. This makes performance bad locally, but completely unusable remotely, even over gigabit ethernet. So -- in a feeble stab at remaining on-topic -- I think that Jython support for IDLE would be a good idea. Unfortunately, there is currently no reliable or well-performing editing component for Java. If we are to move in a direction on some common toolkit, my order of preference is to: * use WxWindows, swigging it for JNI and making the interface match wxPython * remain with Tkinter, try to improve Tkinter support on Java * die slowly from exposure, impaled on rusty metal things * fork IDLE for Java, use an overlay which talks to Tkinter and Swing ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ On Wed, 20 Dec 2000, Fred L. Drake, Jr. wrote: > > Glyph Lefkowitz writes: > > The reason I mentioned it is because I was wondering what you're planning > > to use to do your GUI -- since there is a free AWT, but no free Swing. > > My own experience with Swing (early this year) were that it was just > dog slow and made the process much bigger than it should have been. > This was on a barely-supported system for Sun: Solaris 2.6 on SPARC. > The jTkinter page makes it look promising, but I don't have any time > to play with Jython these days. > > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs at Digital Creations > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > http://www.python.org/mailman/listinfo/idle-dev > From fdrake@acm.org Wed Dec 20 20:14:14 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 20 Dec 2000 15:14:14 -0500 (EST) Subject: [Idle-dev] IDLE and Jython In-Reply-To: References: <14912.65004.447723.799592@cj42289-a.reston1.va.home.com> Message-ID: <14913.4886.16543.532607@cj42289-a.reston1.va.home.com> Glyph Lefkowitz writes: > However, a good indication of how "well-engineered" it is: under X > (presumnably the native engineering environment for Sun people) Swing > regularly sends two or more full pixmap copies of the window per redraw > thanks to the tremendously clever "double-buffering" scheme which all > Swing widgets use. This makes performance bad locally, but completely > unusable remotely, even over gigabit ethernet. Hehehe... that made it mighty unusable on the Ultra/2 I was using at the time! And at 512Mb of RAM (if I remember right!), that's inexcusable! I suspected that the plugable look & feel was a substantial part of the performance problem. > So -- in a feeble stab at remaining on-topic -- I think that Jython > support for IDLE would be a good idea. Unfortunately, there is currently > no reliable or well-performing editing component for Java. If we are to > move in a direction on some common toolkit, my order of preference is to: > > * use WxWindows, swigging it for JNI and making the interface match > wxPython > * remain with Tkinter, try to improve Tkinter support on Java I'd be happy to see either of these happen, but am way too tied up to play with GUI stuff at this point. > * die slowly from exposure, impaled on rusty metal things I'd like to avoid this one, myself. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From mats@laplaza.org Wed Dec 20 21:01:15 2000 From: mats@laplaza.org (Mats Wichmann) Date: Wed, 20 Dec 2000 14:01:15 -0700 Subject: [Idle-dev] IDLE and Jython In-Reply-To: <14913.4886.16543.532607@cj42289-a.reston1.va.home.com> References: <14912.65004.447723.799592@cj42289-a.reston1.va.home.com> Message-ID: <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org> > > So -- in a feeble stab at remaining on-topic -- I think that Jython > > support for IDLE would be a good idea. Unfortunately, there is currently > > no reliable or well-performing editing component for Java. If we are to > > move in a direction on some common toolkit, my order of preference is to: > > > > * use WxWindows, swigging it for JNI and making the interface match > > wxPython > > * remain with Tkinter, try to improve Tkinter support on Java > > I'd be happy to see either of these happen, but am way too tied up >to play with GUI stuff at this point. Hmmm. Looks like Finn Bock was the driver behind jTkinter, and is also very involved in Jython. Maybe he at least has a good picture of the current state of play. I've sent him an email to ask. The project looks like it's been mostly inactive for a year, except for questions just like mine ;-} The need doesn't appear to be exactly _burning_ at this point... one question every six months or so. Mats P.S. Finn left this note in the SourceForge discussion list: "A 100% java/python version of Tkinter would IMHO be an very valuable addtion to JPython. I hope someone will eventually release such a module. My JNI version have some benefits, but I believe a 100% java version would have other useful benefits." From dcalvelo@pharion.univ-lille2.fr Wed Dec 20 23:52:13 2000 From: dcalvelo@pharion.univ-lille2.fr (Daniel Calvelo) Date: Thu, 21 Dec 2000 00:52:13 +0100 (CET) Subject: [Idle-dev] Prettified icons for IDLE browser Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --868297866-944695587-977356333=:30369 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. Somewhere on the README is a complaint about the snake logo in the browser. No more :). Also, the minusnode image had a small distorsion (in the version I got). Excuse the noise if this wasn't the place to send this. I hesitated to use the patch manager at sourceforge, but then this is not a patch, really... Thanks for it all. Daniel. -- Daniel Calvelo Aros calvelo@lifl.fr --868297866-944695587-977356333=:30369 Content-Type: IMAGE/GIF; name="minusnode.gif" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="minusnode.gif" R0lGODlhCwALAJEAAP///39/fwAAAMDAwCH5BAkAAAMALAAAAAALAAsAAAgy AAcIHEhQYICDCBEaBMCwIYAACx0yhDgggMSJCwVo1PgwokSKFi+CvNixYsKE BVMOCAgA --868297866-944695587-977356333=:30369 Content-Type: IMAGE/GIF; name="python.gif" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="python.gif" R0lGODlhDgAPAKL/AAAAAAD/AP8AAMDAwP//AICAAAAA/wAAACH5BAEAAAMA LAAAAAAOAA8AQANCOAqs/kAIBkIBi5XL931DZXUbthiAcZmOGLwBUILMO4ff Au8sfoMhAEEoyy08nhGrNolVjKGJaCYzTVea3BUZGyQAADs= --868297866-944695587-977356333=:30369-- From guido@digicool.com Wed Dec 27 22:33:11 2000 From: guido@digicool.com (Guido van Rossum) Date: Wed, 27 Dec 2000 17:33:11 -0500 Subject: [Idle-dev] IDLE and Jython In-Reply-To: Your message of "Wed, 20 Dec 2000 14:01:15 MST." <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org> References: <14912.65004.447723.799592@cj42289-a.reston1.va.home.com> <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org> Message-ID: <200012272233.RAA22707@cj20424-a.reston1.va.home.com> I happen to be working on a version of IDLE that forks off a subprocess to execute the code. This idea is inspired by previous work of course (Bruce Sherwood c.s.) but this time I'm trying to do it "right". It's not yet ready for prime time, but I believe it would be easy enough to add Jython support: the UI would be using CPython, but the user's code would run in Jython. --Guido van Rossum (home page: http://www.python.org/~guido/) From glyph@twistedmatrix.com Wed Dec 27 23:26:21 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 27 Dec 2000 18:26:21 -0500 (EST) Subject: [Idle-dev] IDLE and Jython In-Reply-To: <200012272233.RAA22707@cj20424-a.reston1.va.home.com> Message-ID: Is there going to be any effort put into making this python 1.5.2 compatible? I would very much like to use IDLE, but the installed base on 1.5.2 is quite large, and 2.0 leaks memory which makes it unsuitable for long-running processes. (and the licensing concerns with 2.0 are unpleasant. (please pardon my ignorance if this has already been resolved!)) ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ On Wed, 27 Dec 2000, Guido van Rossum wrote: > I happen to be working on a version of IDLE that forks off a > subprocess to execute the code. This idea is inspired by previous > work of course (Bruce Sherwood c.s.) but this time I'm trying to do it > "right". > > It's not yet ready for prime time, but I believe it would be easy > enough to add Jython support: the UI would be using CPython, but the > user's code would run in Jython. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > http://www.python.org/mailman/listinfo/idle-dev > From guido@digicool.com Thu Dec 28 01:24:02 2000 From: guido@digicool.com (Guido van Rossum) Date: Wed, 27 Dec 2000 20:24:02 -0500 Subject: [Idle-dev] IDLE and Jython In-Reply-To: Your message of "Wed, 27 Dec 2000 18:26:21 EST." References: Message-ID: <200012280124.UAA23363@cj20424-a.reston1.va.home.com> > Is there going to be any effort put into making this python 1.5.2 > compatible? I don't have the time to test this. I'm not using heavy-duty 2.0 features like Unicode, but the occasional += may slip in. Once this is checked into the 2.1 CVS tree though, I'll gladly accept patches to make it 1.5.2 compatible. > I would very much like to use IDLE, but the installed base on > 1.5.2 is quite large, So here's your reason to switch! > and 2.0 leaks memory which makes it unsuitable for > long-running processes. I resent this unsubstantiated claim. I am not aware of any serious memory leaks in 2.0, and AFAIK none have been reported. (There have been some reports but they wouldn't affect a typical IDLE session.) > (and the licensing concerns with 2.0 are > unpleasant. (please pardon my ignorance if this has already been > resolved!)) It hasn't been resolved, but it will be soon -- there is a basic agreement between FSF and CNRI, which will be implemented hopefully in the coming weeks. (But unless you are intending to combine 2.0 with GPL'ed software, you have nothing to worry about the existing 2.0 license.) --Guido van Rossum (home page: http://www.python.org/~guido/)