From pdfernhout at kurtz-fernhout.com Sun Apr 23 14:41:44 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 23 Apr 2006 08:41:44 -0400 Subject: [Idle-dev] =?iso-8859-1?q?Fwd=3A_Discussion=3A_2_many_IDE=27s=2E?= =?iso-8859-1?q?=2E=2Edon=B4t_we_want_more=3F!?= In-Reply-To: <2078a7ad0602281251p35956fd1pe436a6edd68744ae@mail.gmail.com> References: <2078a7ad0602201618q12f19797p1e0501ae0703fdc2@mail.gmail.com> <2078a7ad0602230811j39c1b3cfk808cbf1f56dac178@mail.gmail.com> <2078a7ad0602241650w26b1f3a3m4e4836471c13940@mail.gmail.com> <2078a7ad0602241700j30061e72nd9db37918d5208b1@mail.gmail.com> <2078a7ad0602281251p35956fd1pe436a6edd68744ae@mail.gmail.com> Message-ID: <444B7608.5060209@kurtz-fernhout.com> Stani- Somewhat belated, but here are some ideas I earlier posted on the edusig list, related to adding some of the featueres of a Squeak Smalltalk development experience to Python, and might be of interest to discuss here. I like the promising idea of developing and debugging across images (or VMs) -- that is, you develop using tools in a VM you are not also changing, but they work across a socket to talk to another VM where your application is running. I have one prototype that does that somewhat (for a custom language); I built a socket server into the VM. I realized later it would probably be better to build a client in instead. That is, you have just one server on the machine, which coordinates client debuggers and client applications, and redirects their messages to each other as a switch board. That way you just use one common port, and can debug multi-VM communications stuff as well. I would try to ship the objects around as pickled Python objects, but would need to look hard at current security issues there; otherwise they would end up as some other format. To support this at first might involve using a separate thread running in the application, and would initially use a sort of module or per function reloading approach, but later the Python VM could be modified to support a debugger socket connection natively. To be clear, what I am going for here is the "feel" of developing in Smalltalk, where you can point your inspector at an arbitrary application, not necessarily the specifics of the Squeak experience. In this case, the Python philosophy of being like glue :-) suggests treating any OS as analogous to a Squeak VM, and finding a way, sockets in this case, to make seemingly different things work together. It's a bit like the notion behind "Dabo" but for development, evaluating one-off Python expressions inspecting existing objects, and debugging. As long as everyone agreed on specific versions of the communications protocol this common subsystem, which would run as a common server, one could use IDE tools written in any language (or Python flavor) and any widget set (even just the command line shell) to debug any application which is a client to this server (including self-referentially the IDEs). I think that might not exactly address this proliferation of IDEs, but it would allow them to be fractured into components that each do what they do best, and the parts of several IDEs could be used selectively together to develop or debug the same application. Remote debugging is nothing new. VisualAge Smalltalk has had it for years, for example, but I think this idea takes it to a whole new level. --Paul Fernhout SPE Stani's Python Editor wrote: > Hi Kurt, Noam and every other IDLE developer, > > I tried to send you this by mail, but maybe it didn't arrive. > drPython and Eric3 joined as well. > > I would be very glad to receive your reaction. > > Thanks in advance, > Stani From guido at python.org Wed Apr 26 01:30:47 2006 From: guido at python.org (Guido van Rossum) Date: Tue, 25 Apr 2006 16:30:47 -0700 Subject: [Idle-dev] =?iso-8859-1?q?Fwd=3A_Discussion=3A_2_many_IDE=27s=2E?= =?iso-8859-1?q?=2E=2Edon=B4t_we_want_more=3F!?= In-Reply-To: <444B7608.5060209@kurtz-fernhout.com> References: <2078a7ad0602201618q12f19797p1e0501ae0703fdc2@mail.gmail.com> <2078a7ad0602230811j39c1b3cfk808cbf1f56dac178@mail.gmail.com> <2078a7ad0602241650w26b1f3a3m4e4836471c13940@mail.gmail.com> <2078a7ad0602241700j30061e72nd9db37918d5208b1@mail.gmail.com> <2078a7ad0602281251p35956fd1pe436a6edd68744ae@mail.gmail.com> <444B7608.5060209@kurtz-fernhout.com> Message-ID: I just stumbled on this thread and found one nugget I'd like to comment on. On 4/23/06, Paul D. Fernhout wrote: > I like the promising idea of developing and debugging across images (or > VMs) -- that is, you develop using tools in a VM you are not also > changing, but they work across a socket to talk to another VM where your > application is running. I have one prototype that does that somewhat (for > a custom language); I built a socket server into the VM. Do you realize that IDLE already solves this? It works exactly the way you say. The mechanism it uses may not be perfect, but it's relatively independent from IDLE, fairly powerful, and has a number of issues worked out that would be a pain to rediscover (including support for Windows as well as Unix). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From redefined.horizons at gmail.com Wed Apr 26 21:45:32 2006 From: redefined.horizons at gmail.com (Redefined Horizons) Date: Wed, 26 Apr 2006 12:45:32 -0700 Subject: [Idle-dev] IDLE Development Plans Message-ID: I'm new to Python, and just started using IDLE last night. I'd like to thank those that have contributed to the development of the IDE, and I had a couple of questions: [1] What are the current development plants for IDLE? Is there a roadmap? [2] What language is IDLE written in? Is it Python or C? [3] Are there any plans to port IDLE to another GUI Framework, or is Tk the way IDLE development will go in the forseeable future? [4] Is there a user mailing list for IDLE? Thanks, Scott Huey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20060426/2e9e9c06/attachment.htm From pdfernhout at kurtz-fernhout.com Thu Apr 27 07:24:11 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Thu, 27 Apr 2006 01:24:11 -0400 Subject: [Idle-dev] =?iso-8859-1?q?Fwd=3A_Discussion=3A_2_many_IDE=27s=2E?= =?iso-8859-1?q?=2E=2Edon=B4t_we_want_more=3F!?= In-Reply-To: References: <2078a7ad0602201618q12f19797p1e0501ae0703fdc2@mail.gmail.com> <2078a7ad0602230811j39c1b3cfk808cbf1f56dac178@mail.gmail.com> <2078a7ad0602241650w26b1f3a3m4e4836471c13940@mail.gmail.com> <2078a7ad0602241700j30061e72nd9db37918d5208b1@mail.gmail.com> <2078a7ad0602281251p35956fd1pe436a6edd68744ae@mail.gmail.com> <444B7608.5060209@kurtz-fernhout.com> Message-ID: <4450557B.5080608@kurtz-fernhout.com> Guido- Thanks for the pointer. I should just expect it by now, but I still am always surprised by how many times I need to solve some problem and find out the Python community already has a good answer. Last I really looked deeply at Idle's code was back when it still had problems debugging my TK apps due to sharing a process (so a very long time ago, but that limitation drove my move away from it way back then). So, anyway, I'm way behind on what Idle does and how it does it. Looks like it's come a long way and I'll need to study up on it. As Idle is now, doesn't it still assume you are first starting Idle, and then doing one thing at a time with it (given the one shell)? I want to support a situation where people are running *lots* of small Python apps (perhaps by lots of different authors), and then when you think, "wow, I want a new widget in this running window", then you can fire up some sort of development tool and try putting the widget in there. Of course, there might need a special tool for each widget library to handle resizing etc. and perhaps then afterwards help you modify the source code of a window creation method for that application if you like the results. It might also be a cool way to develop GUIs from scratch too, not exactly in the Squeakish Morphic and Croquet way which is oriented more toward a direct manipulation philosophy of "what you see is what you get" approach, but more in an abstraction embracing way of "what you see is really neat", where you can bring multiple tools using different graphical and textual representations together to focus on a single problem for a moment. So I might use Idle for a debugger, a variant of BoaConstructor as the object inspector, and a variant of SPE as the source code editor, all looking at the same set of applications and coordinating through sockets. All easier said then done, of course, but I hope you would agree that is potentially a more Pythonic "glue" style approach than, say, directly copying Squeak's approach of having everything (tools and apps) run in the same VM (where one careless change to a window opening method or another essential base class method brings the whole development environment to a standstill). I wonder, if I wanted to build on top of Idle's RPC approach, if I might still need to add an intermediate server, so that when any Python application started (including debuggers or object browsers), it would notify this central server it was online? This would be sort of like a Jabber IM server, but for talkative Python applications instead of talkative people. :-) Or perhaps Idle could do this presence server task somehow with minor changes? Then any collection of development tools written using whatever widget sets (and even in whatever language flavors) could be started up, and they could then be pointed at the already running applications of interest (including hung ones) by querying the presence server for what apps were accessible. Perhaps some development apps like debuggers might even automatically focus on apps that had said they were in need of assistance, say if they threw an unhanded exception. I had been thinking of using twisted, but, given your suggestion, I'll look into whether IDLE's abstract rpc "touch" capability could be extended through various ways to cover remotely touching all aspects of any running Python program. Anyway, time to look at the current Idle code, which will probably take me some time. Just to start with, I'll need to figure out what this comment in "rpc.py" means as far as limitations to N<-->N communications: :-) "For security reasons, GvR requested that Idle's Python execution server process connect to the Idle process, which listens for the connection. Since Idle has has only one client per server, this was not a limitation." Security concerns are obviously a big potential drawback to any socket-based approach, but one thing at a time. When/if I ever have something significant to show, I will probably put it here: http://sourceforge.net/projects/patapata (nothing there now though, just got it approved). --Paul Fernhout Guido van Rossum wrote: > Do you realize that IDLE already solves this? It works exactly the way > you say. The mechanism it uses may not be perfect, but it's relatively > independent from IDLE, fairly powerful, and has a number of issues > worked out that would be a pain to rediscover (including support for > Windows as well as Unix). From dbri.tcc at gmail.com Sun Apr 30 18:29:43 2006 From: dbri.tcc at gmail.com (Don Bright) Date: Sun, 30 Apr 2006 11:29:43 -0500 Subject: [Idle-dev] keybindings on macintosh Message-ID: 1. there is no 'end-of-line' listed in the actions 2. 'beginning of line' on mac keyset should be control-left-arrow like every other program on the mac 3. there is no 'beginning-of-file' listed in the actions 4. there are no 'cursor to next word' and 'cursor to previous word' actions Thanks