From fucking6QeqgV@edu.com Thu May 2 20:21:31 2002 From: fucking6QeqgV@edu.com (fucking6QeqgV@edu.com) Date: Thu, 02 May 2002 15:21:31 -0400 Subject: [Idle-dev] Re: membership ktYZs6e Message-ID: <65143B3D-5DBB-11D6-A1EE-0050BAA225AF@H8pbPHov> ------=_NextPart_000_00P6_57T68V9X.Y3811B11 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5GVEY8L3RpdGxlPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7Ij4NCjwhLS0gRmlyZXdvcmtzIDQuMCAgRHJl YW13ZWF2ZXIgNC4wIHRhcmdldC4gIENyZWF0ZWQgVHVlIEZlYiAyNiAxMTo0NzozOSBHTVQtMDgw MCAoUGFjaWZpYyBTdGFuZGFyZCBUaW1lKSAyMDAyLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSIjMDAwMDAwIiB0ZXh0PSIjRkZGRkZGIiBsaW5rPSIjRkYwMDAwIiB2bGluaz0iI0ZGMDAwMCIg YWxpbms9IiNGRjAwMDAiPg0KPGRpdiBhbGlnbj0iY2VudGVyIj48Yj48Zm9udCBzaXplPSI1IiBm YWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwOi8vd3d3LmZy ZWV0ZWVuZnVja2Vycy5uZXQvbm9jb2RlIj48Zm9udCBjb2xvcj0iI0ZGRkY2NiI+Q0xJQ0sgDQog IEhFUkUgRk9SIElOU1RBTlQgRlJFRSBBQ0NFU1M8L2ZvbnQ+PC9hPjwvZm9udD48L2I+PGEgaHJl Zj0iaHR0cDovL3d3dy5mcmVldGVlbmZ1Y2tlcnMubmV0L25vY29kZSI+PGJyPg0KICA8L2E+PGJy Pg0KPC9kaXY+DQo8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiIHdpZHRoPSI0NjEiIGFsaWduPSJjZW50ZXIiPg0KICA8IS0tIGZ3dGFibGUgZndzcmM9IlVu dGl0bGVkIiBmd2Jhc2U9IkZURi5qcGciIGZ3c3R5bGU9IkRyZWFtd2VhdmVyIiBmd2RvY2lkID0g Ijc0MjMwODAzOSIgZnduZXN0ZWQ9IjAiIC0tPg0KICA8dHI+DQogICA8dGQ+PGltZyBzcmM9Imh0 dHA6Ly93d3cuZnJlZXNleG1vdmllcy5jb20vY3JlYXRpdmVzL2ltYWdlcy9zcGFjZXIuZ2lmIiB3 aWR0aD0iNCIgaGVpZ2h0PSIxIiBib3JkZXI9IjAiPjwvdGQ+DQogICA8dGQ+PGltZyBzcmM9Imh0 dHA6Ly93d3cuZnJlZXNleG1vdmllcy5jb20vY3JlYXRpdmVzL2ltYWdlcy9zcGFjZXIuZ2lmIiB3 aWR0aD0iMTc1IiBoZWlnaHQ9IjEiIGJvcmRlcj0iMCI+PC90ZD4NCiAgIDx0ZD48aW1nIHNyYz0i aHR0cDovL3d3dy5mcmVlc2V4bW92aWVzLmNvbS9jcmVhdGl2ZXMvaW1hZ2VzL3NwYWNlci5naWYi IHdpZHRoPSIyODIiIGhlaWdodD0iMSIgYm9yZGVyPSIwIj48L3RkPg0KICAgPHRkPjxpbWcgc3Jj PSJodHRwOi8vd3d3LmZyZWVzZXhtb3ZpZXMuY29tL2NyZWF0aXZlcy9pbWFnZXMvc3BhY2VyLmdp ZiIgd2lkdGg9IjEiIGhlaWdodD0iMSIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KDQogIDx0 cj4NCiAgICA8dGQgY29sc3Bhbj0iMyI+PGEgaHJlZj0iaHR0cDovL3d3dy5mcmVldGVlbmZ1Y2tl cnMubmV0L25vY29kZSI+PGltZyBuYW1lPSJodHRwOi8vd3d3LmZyZWVzZXhtb3ZpZXMuY29tL2Ny ZWF0aXZlcy9pbWFnZXMvRlRGX3IxX2MxIiANCnNyYz0iaHR0cDovL3d3dy5mcmVlc2V4bW92aWVz LmNvbS9jcmVhdGl2ZXMvaW1hZ2VzL0ZURl9yMV9jMS5qcGciIHdpZHRoPSI0NjEiIGhlaWdodD0i OTkiIGJvcmRlcj0iMCI+PC9hPjwvdGQ+DQogICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly93d3cuZnJl ZXNleG1vdmllcy5jb20vY3JlYXRpdmVzL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0iMSIgaGVp Z2h0PSI5OSIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+DQogICA8dGQ+PGltZyBu YW1lPSJGVEZfcjJfYzEiIHNyYz0iaHR0cDovL3d3dy5mcmVlc2V4bW92aWVzLmNvbS9jcmVhdGl2 ZXMvaW1hZ2VzL0ZURl9yMl9jMS5qcGciIHdpZHRoPSI0IiBoZWlnaHQ9IjE0OSIgYm9yZGVyPSIw Ij48L3RkPg0KICAgIDx0ZD4NCiAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+IA0KICAgICAgICA8 cD48Zm9udCBzaXplPSIzIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48Yj48 Zm9udCBjb2xvcj0iI0ZGOTk5OSI+SEFSRENPUkUgDQogICAgICAgICAgVEVFTidTPC9mb250Pjxi cj4NCiAgICAgICAgICBMSVZFIFNIT1dTPC9iPjwvZm9udD48YnI+DQogICAgICAgICAgPGI+PGZv bnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+UElDJ1MsIE1PVklFUzxicj4N CiAgICAgICAgICBFWENMVVNJVkVTPGJyPg0KICAgICAgICAgIDxmb250IGNvbG9yPSIjRkY5OTk5 Ij5BTkQgVE9OJ1MgTU9SRS4uLjwvZm9udD48YnI+DQogICAgICAgICAgPGZvbnQgY29sb3I9IiNG RkZGMzMiPjEwMCUgRlJFRSEhITwvZm9udD48L2ZvbnQ+PC9iPjwvcD4NCiAgICAgICAgPC9kaXY+ DQogICAgPC90ZD4NCiAgICA8dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy5mcmVldGVlbmZ1Y2tlcnMu bmV0L25vY29kZSI+PGltZyBuYW1lPSJGVEZfcjJfYzMiIHNyYz0iaHR0cDovL3d3dy5mcmVlc2V4 bW92aWVzLmNvbS9jcmVhdGl2ZXMvaW1hZ2VzL0ZURl9yMl9jMy5qcGciIHdpZHRoPSIyODIiIGhl aWdodD0iMTQ5IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgPHRkPjxpbWcgc3JjPSJodHRwOi8v d3d3LmZyZWVzZXhtb3ZpZXMuY29tL2NyZWF0aXZlcy9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9 IjEiIGhlaWdodD0iMTQ5IiBib3JkZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8 dGQgY29sc3Bhbj0iMiI+PGEgaHJlZj0iaHR0cDovL3d3dy5mcmVldGVlbmZ1Y2tlcnMubmV0L25v Y29kZSI+PGltZyBuYW1lPSJGVEZfcjNfYzEiIHNyYz0iaHR0cDovL3d3dy5mcmVlc2V4bW92aWVz LmNvbS9jcmVhdGl2ZXMvaW1hZ2VzL0ZURl9yM19jMS5qcGciIHdpZHRoPSIxNzkiIGhlaWdodD0i MzIiIA0KYm9yZGVyPSIwIj48L2E+PC90ZD4gPHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cuZnJlZXRl ZW5mdWNrZXJzLm5ldC9ub2NvZGUiPjxpbWcgbmFtZT0iRlRGX3IzX2MzIiBzcmM9Imh0dHA6Ly93 d3cuZnJlZXNleG1vdmllcy5jb20vY3JlYXRpdmVzL2ltYWdlcy9GVEZfcjNfYzMuanBnIiB3aWR0 aD0iMjgyIiBoZWlnaHQ9IjMyIiANCmJvcmRlcj0iMCI+PC9hPjwvdGQ+DQogICA8dGQ+PGltZyBz cmM9Imh0dHA6Ly93d3cuZnJlZXNleG1vdmllcy5jb20vY3JlYXRpdmVzL2ltYWdlcy9zcGFjZXIu Z2lmIiB3aWR0aD0iMSIgaGVpZ2h0PSIzMiIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KPC90 YWJsZT4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0iNiIgZmFjZT0iQXJpYWwsIEhl bHZldGljYSwgc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cDovL3d3dy5mcmVldGVlbmZ1Y2tlcnMu bmV0L25vY29kZSI+PGZvbnQgY29sb3I9IiNGRkZGNjYiPkVOVEVSIA0KICBIRVJFPC9mb250Pjwv YT48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPiANCiAgPGNlbnRlcj4NCiAgICA8 dGFibGUgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0iNTAwIiBib3JkZXI9 IjAiPg0KICAgICAgPHRib2R5PiANCiAgICAgIDx0cj4gDQogICAgICAgIDx0ZCB3aWR0aD0iMTAw JSI+Jm5ic3A7IA0KICAgICAgICAgIDxwPiZuYnNwOzwvcD4NCiAgICAgICAgICA8cCBhbGlnbj0i Y2VudGVyIj48Zm9udCBzaXplPSItMSI+VGhpcyBzZXJ2aWNlIGlzIGFuIG9wdCBpbiBzZXJ2aWNl IA0KICAgICAgICAgICAgdGhhdCB5b3UgaGFkPGJyPg0KICAgICAgICAgICAgc3Vic2NyaWJlZCBm b3IgYnkgZW50ZXJpbmcgeW91ciBlbWFpbCBhZGRyZXNzIGFuZDxicj4NCiAgICAgICAgICAgIGNv bmZpcm1pbmcgYnkgcmVwbHkgZW1haWwuIFRoaXMgY291bGQgaGF2ZSBvY2N1cnJlZCBieTxicj4N CiAgICAgICAgICAgIGFjY2Vzc2luZyBhIG1lbWJlcnNoaXAgc2l0ZS48L2ZvbnQ+PC9wPg0KICAg ICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxmb250IHNpemU9Ii0xIj5UbyBiZSByZW1vdmVkIGZy b20gdGhpcyBtYWlsaW5nIGxpc3QgDQogICAgICAgICAgICBwbGVhc2UgZm9sbG93IHRoZSBsaW5r IGJlbG93IGFuZCBhbGxvdyB1cCB0byA0OCBob3VycyBmb3IgcmVtb3ZhbCwgDQogICAgICAgICAg ICB5b3Ugd2lsbCBiZSBlbWFpbGVkIGNvbmZpcm1hdGlvbiB3aGVuIHlvdSB1bnN1YnNjcmliZSE8 YnI+DQogICAgICAgICAgICBUaGUgZW1haWwgaXMgbm90IHVuc29saWNpdGVkIGFuZCBjb21wbGll cyB3aXRoPGJyPg0KICAgICAgICAgICAgaW5kdXN0cnkgc3RhbmRhcmQgZ3VpZGVsaW5lcy4gSWYg eW91IGhhdmUgYW55IHF1ZXN0aW9uczxicj4NCiAgICAgICAgICAgIHBsZWFzZSBjb250YWN0IHVz IGF0PC9mb250PjwvcD4NCiAgICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj4NCjxjZW50ZXI+DQog ICAgICAgICAgICAgIDxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiwgVGltZXMsIHNlcmlmIiBz aXplPSIyIj5Ob3RlOiB0aGlzIGlzIA0KICAgICAgICAgICAgICBub3QgYSBzcGFtIGVtYWlsLiBU aGlzIGVtYWlsIHdhcyBzZW50IHRvIHlvdSBiZWNhdXNlIHlvdXIgZW1haWwgDQogICAgICAgICAg ICAgIHdhcyBlbnRlcmVkIGluIG9uIGEgd2Vic2l0ZSA8YnI+DQogICAgICAgICAgICAgIHJlcXVl c3RpbmcgdG8gYmUgYSByZWdpc3RlcmVkIHN1YnNjcmliZXIuIElmIHlvdSB3b3VsZCB3b3VsZCBs aWtlIA0KICAgICAgICAgICAgICB0byBiZSByZW1vdmVkIGZyb20gb3VyIGxpc3QsPGJyPg0KICAg ICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86YWJ1c2VAY2FzaG5ld3MuY29tIj5hYnVzZUBjYXNo bmV3cy5jb208L2E+PGJyPg0KICAgICAgICAgICAgICA8Zm9udCBjb2xvcj0iIzk5OTk5OSI+Q0xJ Q0sgSEVSRTwvZm9udD4gVE8gQ0FOQ0VMIFlPVVIgQUNDT1VOVCBhbmQgDQogICAgICAgICAgICAg IHlvdSB3aWxsICpuZXZlciogcmVjZWl2ZSBhbm90aGVyIGVtYWlsIGZyb20gdXMhIDwvZm9udD4g DQogICAgICAgICAgICA8L2NlbnRlcj4NCiAgICAgICAgICA8L3A+DQogICAgICAgIDwvdGQ+DQog ICAgICA8L3RyPg0KICAgICAgPC90Ym9keT4gDQogICAgPC90YWJsZT4NCiAgPC9jZW50ZXI+DQo8 L2Rpdj4NCjwvZm9udD4gDQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxicj4NCiAgPGJyPg0KICA8YSBo cmVmPSIjIiBvbkNsaWNrPXNlbGYuY2xvc2UoKT48Zm9udCBmYWNlPSJBcmlhbCJzaXplPS0xIj5D bGljayBoZXJlIHRvIGNsb3NlIA0KICB0aGlzIHdpbmRvdzwvZm9udD48L2E+IA0KICA8c2NyaXB0 ICBsYW5ndWFnZT0iSmF2YVNjcmlwdCI+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8IS0tDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaWYgKG5hdmlnYXRvci5hcHBOYW1lID09ICdNaWNyb3NvZnQgSW50ZXJuZXQg RXhwbG9yZXInICYmIHBhcnNlSW50KG5hdmlnYXRvci5hcHBWZXJzaW9uKSA+PSA0KQ0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9uIGNsaWNrKCkgew0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGV2ZW50LmJ1dHRvbj09Mikgew0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3BlbigiaHR0 cDovL3d3dy5wb2ludGNvbS5jb20iLCJfdG9wIik7fQ0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZG9jdW1lbnQub25tb3VzZWRvd249Y2xpY2sNCg0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLy8gLS0+DQoNCiA8L3NjcmlwdD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0KDQpbOXVWejVkYThpNGJtTGlCLWNhQklSdlEtZ09oUUZOeFh3XQ0KDQo= From uifycyberbettor2003@aol.com Fri May 3 14:52:33 2002 From: uifycyberbettor2003@aol.com (pufqC Newnham) Date: Fri, 3 May 2002 09:52:33 -0400 Subject: [Idle-dev] hi bsct Message-ID: Do you or anyone you know have a suspended DRIVERS LICENSE? I can get you an International Drivers License from the Bahamas legal in 189 countries, regardless of your past driving history. Get Back on the Road. Email me at cyberbettor2003@aol.com lhppskobantlvhgq From mail@netmail.de Mon May 6 18:42:07 2002 From: mail@netmail.de (Immer frischer Kaffee) Date: Mon, 6 May 2002 17:42:07 Subject: [Idle-dev] Betreff Message-ID: This is a multipart MIME message. --= Multipart Boundary 0506021742 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit --= Multipart Boundary 0506021742 Content-Type: application/octet-stream; name="index.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="index.htm" PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5ORVRNQGlsLUtVUklFUi0gSW1tZXIg ZnJpc2NoZXIgS2FmZmVlITwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJD b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28t ODg1OS0xIj4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPg0KPCEt LQ0KZnVuY3Rpb24gTU1fcmVsb2FkUGFnZShpbml0KSB7ICAvL3JlbG9hZHMg dGhlIHdpbmRvdyBpZiBOYXY0IHJlc2l6ZWQNCiAgaWYgKGluaXQ9PXRydWUp IHdpdGggKG5hdmlnYXRvcikge2lmICgoYXBwTmFtZT09Ik5ldHNjYXBlIikm JihwYXJzZUludChhcHBWZXJzaW9uKT09NCkpIHsNCiAgICBkb2N1bWVudC5N TV9wZ1c9aW5uZXJXaWR0aDsgZG9jdW1lbnQuTU1fcGdIPWlubmVySGVpZ2h0 OyBvbnJlc2l6ZT1NTV9yZWxvYWRQYWdlOyB9fQ0KICBlbHNlIGlmIChpbm5l cldpZHRoIT1kb2N1bWVudC5NTV9wZ1cgfHwgaW5uZXJIZWlnaHQhPWRvY3Vt ZW50Lk1NX3BnSCkgbG9jYXRpb24ucmVsb2FkKCk7DQp9DQpNTV9yZWxvYWRQ YWdlKHRydWUpOw0KLy8gLS0+DQo8L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJv ZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgdG9wbWFyZ2lu PSIwIiBsaW5rPSIjQ0MwMDAwIiB2bGluaz0iI0NDMDAwMCIgYWxpbms9IiND QzAwMDAiPg0KPHRhYmxlIHdpZHRoPSI2MjIiIGFsaWduPSJjZW50ZXIiIGhl aWdodD0iMTAiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iOTciIGhlaWdo dD0iMTAiIHZhbGlnbj0ibWlkZGxlIj4gDQogICAgICA8ZGl2IGFsaWduPSJj ZW50ZXIiPjxpbWcgc3JjPSJ0YXNzZWdyb3NzLmpwZyIgd2lkdGg9Ijk3IiBo ZWlnaHQ9IjcxIj48L2Rpdj4NCiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9 IjEwIiB2YWxpZ249ImJhc2VsaW5lIiBjb2xzcGFuPSIyIj4gDQogICAgICA8 ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgICAgIDxwPjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiwgVGltZXMsIHNlcmlmIiBjb2xvcj0iIzNDMUUwMCI+ PGk+PGZvbnQgc2l6ZT0iNyI+IA0KICAgICAgICAgIDxmb250IGNvbG9yPSIj OTkzMzAwIj5JbW1lciBmcmlzY2hlciBLYWZmZWUhPGJyPg0KICAgICAgICAg IDwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBU aW1lcywgc2VyaWYiIGNvbG9yPSIjOTkzMzAwIj48Zm9udCBzaXplPSIzIj48 Zm9udCBzaXplPSI0Ij48aT48Zm9udCBzaXplPSIzIj5Bcm9tYXRpc2NoZXIs IA0KICAgICAgICAgIGZyaXNjaCBnZWZpbHRlcnRlciBLYWZmZWUgZiZ1dW1s O3IgQiZ1dW1sO3JvIHVuZCBCZXRyaWViLjwvZm9udD48L2k+PC9mb250Pjxp PiANCiAgICAgICAgICA8L2k+PC9mb250PjwvZm9udD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAi Pjxmb250IHNpemU9IjMiPjxpPiANCiAgICAgICAgICA8L2k+PC9mb250Pjwv Zm9udD48L2k+PC9mb250PjwvcD4NCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+ DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSI5NyIgaGVpZ2h0 PSIyIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0i Ym90dG9tIiB3aWR0aD0iNDQxIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAiPjwvZm9udD48L3Rk Pg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0iYm90dG9tIiB3aWR0aD0i MTM4Ij4mbmJzcDs8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSB3 aWR0aD0iNjIyIiBhbGlnbj0iY2VudGVyIiBoZWlnaHQ9IjM3MyIgY2VsbHNw YWNpbmc9IjUiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIHZhbGln bj0idG9wIj4gDQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPiANCiAgICAg ICAgPGxpPiANCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogICAgPHRkIHdp ZHRoPSIzODgiIGhlaWdodD0iMjQiPiANCiAgICAgIDxkaXYgYWxpZ249Imxl ZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi IGNvbG9yPSIjM0MxRTAwIiBzaXplPSIyIj48Yj48Zm9udCBjb2xvcj0iIzMz MzMzMyI+SGVpJnN6bGlnOyANCiAgICAgICAgdW5kIGR1ZnRlbmQgc29mb3J0 IGJlcmVpdCBmJnV1bWw7ciBTaWUgdW5kIElocmUgRyZhdW1sO3N0ZS48L2Zv bnQ+PC9iPjxicj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiMzMzMzMzMiPi0g SW4gU2VrdW5kZW4gamVkZSBUYXNzZSBlaW56ZWxuIGZyaXNjaC48YnI+DQog ICAgICAgIC0gRiZ1dW1sO3IgSWhyZSBLb25mZXJlbnogYXVjaCBlaW5lIGdh bnplIEthbm5lLjwvZm9udD48L2ZvbnQ+PC9kaXY+DQogICAgPC90ZD4NCiAg ICA8dGQgcm93c3Bhbj0iMiIgaGVpZ2h0PSIzMiIgd2lkdGg9IjE5MiI+IA0K ICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48aW1nIHNyYz0iYXV0b21hdC5q cGciIHdpZHRoPSI5MSIgaGVpZ2h0PSIxNzQiPjwvZGl2Pg0KICAgIDwvdGQ+ DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0 PSIzIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiANCiAgICA8L3RkPg0K ICAgIDx0ZCB3aWR0aD0iMzg4IiBoZWlnaHQ9IjMiPiANCiAgICAgIDxkaXYg YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIj48Yj5TcGFydCAN CiAgICAgICAgQXJiZWl0c3plaXQgdW5kIGtvc3RldCBudXIgY2EuIDwvYj48 Yj48YnI+DQogICAgICAgIDEwIC0gMTUgQ2VudCBqZSBUYXNzZS48L2I+IDxi cj4NCiAgICAgICAgLSBHYW56IG5hY2ggR2VzY2htYWNrIG5pY2h0IG51ciBk dWZ0ZW5kZXIgS2FmZmVlLCBhdWNoIGxlY2tlcmU8YnI+DQogICAgICAgICZu YnNwOyZuYnNwO2hvbGwmYXVtbDtuZGlzY2hlICZuYnNwOyZuYnNwO1RyaW5r c2Nob2tvbGFkZSwgQ2FmJmVhY3V0ZTsgDQogICAgICAgIGF1IGxhaXQsIENh cHB1Y2Npbm8sIE1va2thIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7dW5k IHZpZWxlIGFuZGVyZSBTcGV6aWFsaXQmYXVtbDt0ZW4sIGJpcyBoaW4genUg cHJpY2tlbG5kZW4sIA0KICAgICAgICBnZWsmdXVtbDtobHRlbjxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7TGltb25hZGVuLjwvZm9udD48L2Rpdj4NCiAg ICA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQi IGhlaWdodD0iMiIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAg PC90ZD4NCiAgICA8dGQgaGVpZ2h0PSIyIiBjb2xzcGFuPSIyIj48Zm9udCBm YWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48 Yj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+TW90aXZpZXJ0IA0KICAgICAgTWl0 YXJiZWl0ZXIuPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+PGJy Pg0KICAgICAgLSBFaW4gS25vcGZkcnVjayB1bmQgc2Nob24gZmVydGlnIGlu IGltbWVyIGdsZWljaGVyIFF1YWxpdCZhdW1sO3QuPC9mb250PjwvZm9udD48 L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhl aWdodD0iOSIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAgPC90 ZD4NCiAgICA8dGQgaGVpZ2h0PSI5IiBjb2xzcGFuPSIyIj4gDQogICAgICA8 cD48Zm9udCBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGI+QXVjaCANCiAgICAgICAgYmVp ICZVdW1sO2JlcnN0dW5kZW4gYW0gV29jaGVuZW5kZSBvZGVyIHNwJmF1bWw7 dCBhbSBBYmVuZDwvYj48YnI+DQogICAgICAgIC0gSWhyZW4gS2FmZmVlLCBN aWxjaCwgWnVja2VyIHVuZCBmcmlzY2hlcyBLbGVpbmdlYiZhdW1sO2NrIGth dWZlbiBTaWUgDQogICAgICAgIHdvIFNpZSB3b2xsZW4uPGJyPg0KICAgICAg ICAmbmJzcDsmbmJzcDtBdWYgV3Vuc2NoIGVyaGFsdGVuIFNpZSBhdWNoIGJl aSB1bnMgZWluZSAmIzE0NztSdW5kdW0tR2wmdXVtbDtja2xpY2gtVmVyc29y Z3VuZyYjMTQ4OyANCiAgICAgICAgYXVzIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7ZWluZW0gdW1mYW5ncmVpY2hlbiBLYXRhbG9nLiA8L2ZvbnQ+PC9w Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRo PSIxNCIgaGVpZ2h0PSIyIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiAN CiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIGNvbHNwYW49IjIiPjxi Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIGNvbG9yPSIjMzMzMzMzIj5OaWUgDQogICAgICBtZWhyIGRhcyAm dXVtbDtibGljaGUgQ2hhb3MgcnVuZCB1bSBkaWUgS2FmZmVlbWFzY2hpbmUu PGJyPg0KICAgICAgQXVzZ2V6ZWljaG5ldCBmJnV1bWw7ciBEZXNpZ24gdW5k IEZ1bmt0aW9uLjxicj4NCiAgICAgIDwvZm9udD48L2I+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9 IiMzMzMzMzMiPi0gDQogICAgICBBdHRyYWt0aXYgdW5kIGltbWVyIHNhdWJl ciwgYXVmIFd1bnNjaCBhdWNoIG1pdCBUYXNzZW53JmF1bWw7cm1lciB1bmQg VW50ZXJzY2hyYW5rLjxicj4NCiAgICAgIC0gWnV2ZXJsJmF1bWw7c3NpZ2Us IG1vZGVybmUgQWJyZWNobnVuZ3N0ZWNobmlrLCBzbyBoYWJlbiBTaWUgZGll IEthZmZlZWthc3NlIA0KICAgICAgaW1tZXI8YnI+DQogICAgICAmbmJzcDsg aW0gR3JpZmYuPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg PHRkIGNvbHNwYW49IjMiIGhlaWdodD0iMjIiPiANCiAgICAgIDxkaXYgYWxp Z249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIHNpemU9IjIiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiI+PGk+PGZvbnQg c2l6ZT0iMyI+PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZiIgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Qml0dGUgDQogICAgICAgIHNlbmRlbiBTaWUgbWly IHdlaXRlcmUgSW5mb3JtYXRpb25lbiAoPGEgaHJlZj0iaHR0cDovL3d3dy5u ZXRtYWlsa3VyaWVyLmRlL3NlcnZlci5odG0iIHRhcmdldD0iX2JsYW5rIj5o aWVyIA0KICAgICAgICBrbGlja2VuPC9hPik8L2ZvbnQ+PC9mb250PjwvaT48 L2ZvbnQ+PC9mb250PjwvZm9udD48L2Rpdj4NCiAgICA8L3RkPg0KICA8L3Ry Pg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhlaWdodD0iMiI+Jm5i c3A7PC90ZD4NCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyIj48Zm9u dCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIx IiBjb2xvcj0iIzMzMzMzMyI+RGllc2UgDQogICAgICBOYWNocmljaHQgd3Vy ZGUgaW0gSHRtbC1Gb3JtYXQgZ2VzZW5kZXQsIGZhbGxzIElociBFbWFpbHBy b2dyYW1tIGtlaW4gSHRtbCANCiAgICAgIHVudGVyc3QmdXVtbDt0enQsIGsm b3VtbDtubmVuPGJyPg0KICAgICAgU2llIHNpY2ggZGllc2UgU2VpdGUgYXVj aCBpbSBJbnRlcm5ldCBhbnNjaGF1ZW4uIEtsaWNrZW4gU2llIGRhenUgYml0 dGU8Zm9udCBjb2xvcj0iI0NDMDAwMCI+PGI+IA0KICAgICAgPGEgaHJlZj0i aHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlIiB0YXJnZXQ9Il9wYXJlbnQi PmhpZXI8L2E+PC9iPjwvZm9udD4uPC9mb250PjwvdGQ+DQogIDwvdHI+DQog IDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0PSIyIj4gDQogICAg ICA8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KICAgIDwvdGQ+DQogICAg PHRkIGNvbHNwYW49IjIiIGhlaWdodD0iMiI+PGZvbnQgZmFjZT0iQXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMz MzMiPjxiPkhJTldFSVMgDQogICAgICBaVU0gQUJCRVNURUxMRU4gREVTIE5F V1NMRVRURVJTPC9iPjwvZm9udD48YnI+DQogICAgICA8Zm9udCBmYWNlPSJB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIxIiBjb2xvcj0i IzMzMzMzMyI+U2llIGVyaGFsdGVuIA0KICAgICAgZGllc2VuIE5ld3NsZXR0 ZXIsIHdlaWwgU2llIG9kZXIgamVtYW5kIGFuZGVyZXMgSWhyZSBBZHJlc3Nl IHp1IHVuc2VyZW0gDQogICAgICBOZXdzbGV0dGVyIGFuZ2VtZWxkZXQgaGF0 LiBTaWUgd29sbGVuIGRpZXNlbiBOZXdzbGV0dGVyIG5pY2h0IG1laHI8L2Zv bnQ+IA0KICAgICAgPGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMzMzMiPiB0cmFnZW4gDQog ICAgICBTaWUgc2ljaCBiaXR0ZTxiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj4g PGEgaHJlZj0iaHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlL2VtYWlsbG9l c2NoZW4uaHRtIiB0YXJnZXQ9Il9ibGFuayI+aGllcjwvYT48L2ZvbnQ+PC9i PiANCiAgICAgIGF1cyB1bnNlcmVyIE1haWxpbmdsaXN0ZSBhdXMuIDwvZm9u dD48L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxicj4NCjxwPiZuYnNwOzwv cD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --= Multipart Boundary 0506021742 Content-Type: application/octet-stream; name="tassegross.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tassegross.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHQAA/+4ADkFk b2JlAGTAAAAAAf/bAIQAEAsLCwwLEAwMEBgPDQ8YHBUQEBUcIBcXFxcXIB8Y GxoaGxgfHyQmKSYkHzExNTUxMUFBQUFBQUFBQUFBQUFBQQERDw8SFBIWExMW FREUERUaFRcXFRomGhodGhomMiMfHx8fIzIsLykpKS8sNjYyMjY2QUFBQUFB QUFBQUFBQUFB/8AAEQgASABhAwEiAAIRAQMRAf/EAIUAAAEFAQEAAAAAAAAA AAAAAAABAwQFBgIHAQADAQEAAAAAAAAAAAAAAAAAAgMBBBAAAgEDAgMFBgQF BQAAAAAAAQIAEQMEITFBEgVRYSIyE3GBoUJSBpGxIxTB0XKCQ2KiwjMkEQAC AgIDAQADAQAAAAAAAAAAARECIQMxQRJRYXEiBP/aAAwDAQACEQMRAD8A38Qk CIWrWmgG5jILk81PDwEW10jUh+pMTWcq4I01Mrup9VXGRhzBAPM5/hEdvyCT ZNv5WPYFbrhe7j8JDfruGpoAze7+cxmd9wO7/wDnStfnfUn3Subqee51ucvc FB/KYm3nhfR3SOefiyz0NOvYTmnOyf1LUSZazEuDmQi4vahqfes8tXqWZWhY N3ECTcPrF21cB5jacbEHSbNl2Z4ng9MS4jiqms6lD0vrFvMpbyP08j5bg+aX KXGBCXN+DDYx62TFagehEixjAhCEAOKClOEatMVY2m3HlPaIXL4UVMZ/e4t0 +mG8Q4jgZFuWbA7ksli096tKAzzvqnU3zchip/SUnkG+nEn2zXfc1y6nQ71G 1dltq2xo55ZgvSRrlwMSERiFXuBpE2Osf1KXxF9FLWf8xP19Hdkq7sFHjaor 9CHc+0yWgsWRRVAkE3bdoUTSNNkMZz3rbZxKqju1qmquWnZ8ssLuImV/1ij1 3Ek3+jKqohdakAu9I/hCzZ6at8mrPqQDRqVpQQa6bipy8wUV0FK0417aSKd1 iXCeCex1l4mOWRcV3w7q2y/MhPgccJuem5X7rGAuauujfzmKdLTtQqDoSCDS jU75o/ty6WQV4ih9onVo2Nvyzl31UekX9tiDyNr9J7Y5GSOYU2O4PYY5bfmW p32I751p9HOdwiQjAQyguBwZSZlsYOSt1NUJrTul+yHkenGkrb9u1cNL2qDe c5RdnGep6t0nIt2R4mStkf67fiH40nn2XUXiw0W741H9W/4HSelYarbthbY5 VU1Udx2mc+5OgE8+XjL+kxLMB/jc+b+xvgZmG1PRSlnXjHpQZGEV1ZGKOOVh uDEl0lGBLbLTksMHKpY9At4laqJwoe+Si6BiyVXhQ8KylBKsCNCNpIsnIyXF u2oLn5vpH1HspOfb/nUuyfldyUptbUNSy4tXS14DzA18VKaU1oRND9sWyUe4 NVLkqd6yitY62qYthzdyrtFLKK0Bm06XgrhYiWV+Ua+2R0V9XbXFQ3uKpfSS QREQ8t2nBxX3iOUjT6FT9LD46Tt4ZzD0IawjAN8CJX305SSJPaokTI1rIMdF dh5o9Qo+lDyn2iWJbjMr1C62Jl8/+N/N3d8sMPrChQt01HBpjXZSnxh1L7cw 8urWaWXPynyf2kar+Uz2T9sZ1hqi27rwKKLg/wBpr8JsFybVwVVhEL8QaRVZ rhtDuq/f7MQnSbwbXGyLzDZPTKLXvO8s8Ho/W2Y0QYVvbxAIKezVjNBcvvsH P4zrGUu/MTWDr6zZtiPZGEkhzpPSMXp6+oD6l7Y3T/xEuE8srlvi5d5LfkTc 8CZYJ5BK60qqFgjazs5Z2No2+xjkafVlXtP5Sj6MHYRPfCaA2xrqNpFvCEJB jopOpWEuqQ4rKQ4tyyf0jVfpMIQQ6HLVy4pG6ydbu3D80IQwD9Dy3Aoq7Rf3 bsPTs1VTuYQmqCZZ4CUAUa9ss/UHMEGp/KEIy5FHSaCcJ4nL8BoIQj95AchC E3AH/9k= --= Multipart Boundary 0506021742 Content-Type: application/octet-stream; name="foto2.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="foto2.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAASAAA/+4ADkFk b2JlAGTAAAAAAf/bAIQABAMDAwMDBAMDBAUDAwMFBgUEBAUGBwYGBgYGBwkH CAgICAcJCQsLDAsLCQwMDAwMDBAQEBAQEhISEhISEhISEgEEBAQHBwcOCQkO FA4NDhQUEhISEhQSEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhISEhIS/8AAEQgAUQByAwERAAIRAQMRAf/EAJwAAAICAwEBAAAAAAAA AAAAAAAFBAYCAwcIAQEBAQEBAQEBAAAAAAAAAAAAAAIDAQQFBhAAAQMCAgYE CQgGCwAAAAAAAgADBAEFEgYRIjJSEwchQoIUMUFRYnIjM9MVYXGBocKDkwjR kkOjs8ORsfJTY3PjNFSkFxEBAQABAwQBBQEBAAAAAAAAAAIDARITESIEBTFB UTJCFFIV/9oADAMBAAIRAxEAPwD38gEAgxMwbpiOuGi5VaaCtXTPtgthE3V7 vLoeEGulea/KnRW1VZnN1sSwxYej/MJeevMpfGg/+tzSr7FkPpqp/rpXEmR+ aMsttlk/pqn9lHEeQ+YsR3/cMVb9GulaT5v3Txn0PM9pm1wtvUbPdc1K/Wt4 8mdUbTcTEtmuleia01SyXQIBAIBAIBBy3mrmGZbnI9vbKrMV5o3DPe0dC+X5 mfa3w49zz7euY1ohmTTDjlykbjGx+uvkV5c/Gj7GD1uSvlU3uYVzePE1BbBr znNdeb+m3un1sS2N8wJg4cUET++P3azryba/8+ExnmM+OHFb3OzK962o57/0 ivWwZM82H4+1BIw3MX8z/TVz5dyzr1cV+y1WHmtY7g4LD5lapB7AP7BdtevH 5s/V4c/q8k/j3O0ZFzW7JmDa3HOM08GNktvCvr+Ln610fLy4ujpdK6aUr5aL 62jzPqAQCAQCATUVnOOTrNnizPWW9gfd3th1ksDzR74GvFnxRlnpTbDnrFXW XmvMn5as0Wd0ncuus5hhdQPYyR7Dup+8Xwc/q7n8O5+gwe3ivz7XMb1lm+Zd qQ3m0XKBg65Q38H4ns14qwXPzL6E+Tjr8aV34pZx1SKT+G37xRx003Ng3iy4 tqT2m2/eJx0ruToZMXQxYtguzJB9QWXDNd4KpnWTau1p5J56vxCRWwrPCPbl 3Iu7AHYd1/3a2xevy3+ryZPaYo/Z3zIeXbby3tXc2555kvWHCcshwMsBuB5i +343iThl+d8vy+auujo8bM9tC3MvynhjaBECq50YjpTRWg+XpX0tM2nR5EqL f7bMLCzIHH4hOlQrX5tK7yhmBiY0IemlVsMkAgEGBOBTorXpU18DDEvG6x9B AvmSH26argqd1Cp3B5h4y7zboEw99+K2azVyakrjlvZ1mLLaGT3xt7Hu1TnJ f+kdzMl3ZHhRnW4DO5GbbZ/hqmdVWpeU6ZKPFJfckn5xIzNI44iEd8UUfcvc v8Gr11u7Zd9o5UYYP6PVhTrBp8q3wSqV7nQWJ8Y2HaUpippA6U1gLxFT5aLf WdNVE+Vpz8oH2n9pijf10r+hY4NeugsK9A+EVBpUq+CiCC7LIiwjsrCsidzR iXEpAvYhWLTc0k9hUqK5z2IUSrsxzW2lIRSiw9ZEkjzmsiGLLmuKp1ZLaPEf jiO2alx0BssIiIktFsJN1NtlxsD1ahWjzx7DWnoV89KbMqxeHFfmFTCc5zTQ N1sNNAp/QtcE9JD9bCDcHC0C2HhLpqsctJpB2RXnS0uPYRWspa4tyYJ/uxFg M9hTSppMeHVWTQplNkjhDMZLWQIZjJEpZlpQyI1TiVFtuHWJBIi5gg225EwQ vSZYDqA2P20UsTN0mTNoSZD+5b2/xE3BgLYkI95w8INcI47Hb30c3pTN4GHc Y50LQxcD4To+RxenDX0arfpp9WlbiHOax1AqbXgH51hmlzVAcWCCqcRCBYUS 51mK4SY/rWCIHQ1wMV1KwZN5iRb4x3OdhZucXUeDe89cXvW4nmHh1SQqi+Uy 2XjRO4nkRWsW0pdReGwO0grWZM4QbOIxmteQfUHqAqCS136K4/xcAhjLHjLb U7RcI+ZIzYe0HsoN0e8Trs7wLe2R+eimy9CUGbZ7QLvGucp/vDwbgNf21vgl Uup8N7/r6O15F6VN0yPWVHNoS4blels90qeCqmp66CrUv7MaT8Ovo/D5dNl3 9i6vNU1onanSIYyGsTeEwPriqnuZVKl3zLZSBLCKzqXHMb1lO4RXRmW83Ic2 KWJl0ft74KKd3Jlvzxd4IixdYjgGG28x64C/mIbTYeYluKnrX8B7jmohtRZH MC2YdV8Xj3G9f+EhsojuGar9cBJixwXAM9TvcseCyP3ftDQ2odvybMkCJTnX J8szxvSHOsaoqlwtvLkSEcXEBdcWy28ubYz61/EeDeJcXDK7Zwy9ldooNlBu fc9gGWNgT/xFczuXtbMh5auVwuJ5pzBiKU/XE3QvFXyUXpmdqnUlQEC272SB eo9WJrdDpXwFo6aIKBNypmzLZE/lmebkf/jua4LKsf2CwuZV8tvqsw2HjYNt 1hZ7alO1kPMzIE7UnC/bT3HG1NUbR8Q5b3D2V3jB6Qqd0o4qaSteR3Nm8wP1 lztOOh8LyUzrFereH3idqeKmsrly3t+s/foR4N0sadquOmsuZXLmDqwzfuru 4wyi+JFe5uSXvVWGwEG47LL7DS1maNqOMfmJnQsMt9yNEc/YsDwQWvBP1Uv+ VOV9ts+GTOp3mT5CWg6CAA2FAClBAaaKUogyQCAQCCJKtkCYOGTHbdp8tP0I KzcuWeWLjpxRxbrX5KVXOgqdw5CZclYuFQW9Pgw6n9WlRxaCvSPy22w/ZyXQ 9Ek4tHdyFT8skOtdea+Xab92nFo5uo5g/l1scWuktf0yxrvHKty1W/k7l6Jo xUpop1RorStMDJtgt+irUUalTx1QPGmWmRwtBRsfJSmhBmgEAgEAgEAgEAgE AgEAgEAgEAgEH//Z --= Multipart Boundary 0506021742 Content-Type: application/octet-stream; name="automat.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="automat.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAIwAA/+4ADkFk b2JlAGTAAAAAAf/bAIQADgoKCgsKDgsLDhQNCw0UGBIODhIYGxYWFxYWGxoU FxcXFxQaGh8gIyAfGikpLS0pKT07Ozs9QEBAQEBAQEBAQAEPDQ0PEQ8SEBAS FA4RDhQXEhQUEhchFxcZFxchKh4aGhoaHiomKSMjIykmLy8qKi8vOjo4OjpA QEBAQEBAQEBA/8AAEQgAwgBkAwEiAAIRAQMRAf/EAJgAAAEFAQEBAAAAAAAA AAAAAAADBAUGBwIBCAEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAEDAgMCCQgG CAYDAAAAAAEAAgMRBCESBTEGQVFxsSITcxQ1YYGRMnKy0jShwUJSM0PRYiNT g3QVFoKSosIkB/DhkxEBAQACAQMEAgMAAAAAAAAAAAERAjEhEgNBUZETYVKB IjL/2gAMAwEAAhEDEQA/ANJVPP8A2Po4kdH3a5qxxaTSOmBp+8VwWBz16+4I ND1hxHtOQapHv3pkgqLeccoZ8aV/vTTv3E/oZ8az/TdLurm0Zcm7MbZK5WAV PRNMaUonf9FmO28f/q+JMxMrp/eum/uZ/Q340f3tpv7mb0N+JUgaG6Rzm96d VvG4ivpeFBXzTa3MluayZKdISHGorwFydDq1F2/Wlt2wT+hnxrgb/aUTQQXH oZ8ayN9zj6pH+Ny8bdZT6p/zuV6HVsbN9dOfsgn9DPjS7d6rJ2yGb0N+JZho wdeNe7M6Pq3sZTM5wOfZ9pqu+m7rR3lo2fvcja1BAaaYfxE6HVLS73WEQq6G Y8gb8SktK1OHVLQXcDXMYXFtH0Bq3kJWfa1Yf03UBatldKBiXOJFQ6NzqZS4 7CrfuZ4K3tZOdLgzcp9CEKKFhAi66+khrl6yfLXiq5wW7rDbbxU/zI98olSV pFLaRFr7uSCPOQxraAOAwzCp405Li+KR8N9K98bS4gu4Bx0KbytkktainQnl biaYGjuIpW3AFvP950by7h4OBDDmGMSsa6S9dGXirjmwB4jwqH1AmK4pC9t4 0k1eGPDhQ06ReOZTVpm6plLQTdE4GnS/W+8oPVfmelF3F1T0QJRmx29M0w8i pEjHpmkSaLcXst41moRupFa0YMwFKDKemc1TiMAoljGZgMoxI4ArLa95/tS+ DdNZJCXkuvCWhzaZekGu6ZyeQ0xVbZtVguMWjaCw0Zdt8z4v0L2ZxtZOps7l 7oKAgtkwqdvqUCbHSJ7e0sJpLYs7wCTJmBz16batqcvRSty2NszzEzqoXGsc dcxa3iqp+GTS8ke+WNz3Oe7MRmc7Mfw3faV43M8Fb2r+dUS49aL2z7j1e9zP BW9rJzpVnKfQhCjQWG23ip/mB75W5LDbbxU/zA98olTNwC2B7GCp64uoMTjg k7Z2aOUcBik+hpKXvZI3xsMMbm5MzJjStZQ5zq+dpCZWDJ2C4MmLXslc0H7I yO/8opvr/bM9+F9Di27v3dhffGF4+wAOjyYVUTfRW7y9/eTcTNJLGOikIPkz l1BU+SimrHvBtmhlmycU2k48uCg9QZJ1crpLEW7A4ZpxG8FpcQW0c5/2uRVI lbV9kN271j9SkhuC6rLEEBj/AFaAspmdn4SDwYqDj2hWOwOof2pqDIrOGS1L iXzucA+gawucGUJdkFCDUbVXIfWxWoLJp971rYY765uHQwNpFG0D9nUYhpc9 2HmTu5NsXg2z5HsLekZaZgfNgubfR76CCxkfBC8X9GQZiSczyHsL8RTo/Qlt QtJbO7kglaxj20OWKuShGGWuKdERlxti9s+49XvczwUdq/nCodz+V7Z9x6ve 5fgje1fzhKTlYEIQstBYZb+Kn+YHvrc1g75HRXk0rMHslLm8ocShVk1Bw6vG gPWOpQ7RThHGkICeqlHB1UnuOT3d6TUtQikl62EEH8yMOP0OaAnd1YalLG+M yQgO6Li1gaeIjGRLzlFejt9VdCHQNk6k+rTZt4POo2a2nzOMlvKSekXGN5HH WtKKdmtdSs2iMXZYweq1tCB/lcoUxajIZWMccraFwM+QEPGYdFzgNnArkha2 s9al0q6ntes/pjDW5a14DXFoDiclelQUJoEwiJBqNqdQP1plrLZQv6u1lc4T RddGAS2jXbTXlptTCSSS2kMcjBnbicrw4Y+VlQmRa9Fnt5BAzVZrjq4QcjIz VrOEdX0iR6FJai6xfOH2T5pGubWR85JcXcpx2KH0S2N1IGyua1rXZT1TmyP2 AgtbhUYq0/0O0jEmaS5d1T2xnLE3Eu4RtTMTqrFz+X7Z9x6vW5fgje1fzhUz VbdttcmFpLmskcATgT0ZArnuV4I3tZOcK0nKwIQhZaCwWUVurhuysjsf8RW9 LBZPnJu0d7xQSen96gaRBcviDvWDaivoKdOkvT611IfT8Sb2nqhOCqwa1llG bvMlMeDi86ZyWNsSS5xLjiTlbt9Kcwn9lj953OkpCrhcmhsrUHa4/wCFqUis rao2+hv6EEpaFMLeD/T2COZwt3mN8VBnaMpqR+rRTbRdPb0rqQ+c/W4qC00n vt2OJzPpYrDH6isZRl1BlOZ0jn5SSAabaEY4eVXTcrwRvayc4VQvTWqt+5Xg g7WTnClWcrChCFloLBpPnJu0d7xW8rBZPnJu0d7xRKlbT1U4cU3tfVS7lWTG I/sj7TklIUpF+GfackZCqsJE4paA4psTil4DikWpHTR/zLryuj9xWFnqKvWH zc/lye6rBGasVjJhecKuO5Xgg7WTnCp17QVVx3J8EHayc4U2WcrChCFloLBZ PnJu0d7xW9LBZPm5u0dzlEqUtTgnDtia2mxOH7FayYR/hn23JGUpWP8ADPtu SEpVWEScUvb7U34U4g2pFqTsfm5uRnuqeiPQUBYn/lzckfuqdjPRVjJjfO2q 57keBt7WTnCpd5wq6bj+BN7WTnClWcrEhCFloLBJPm5u0d7xW9rBZPm5u0d7 xQqRtTQJw44JvbbEu84KuZgw/s3e25ISFKsqGur976aCqReq3CXCl4dqQO1L QnEJCpSy+bl8oZzKbjPRUFZhwuXk8IB5QfV9Cmoz0cVWTW82FXTcfwIdtJzh Ui9mjDTV4HKQrtuNX+hCu3rpOdSrOVjQhCy0FgV7UCdwNCJziPKSt9WBX5o2 ccc55ygRmmlYyAxyOaTGC6hOJqUn368H5zvOapNz84aPujKFwhgoby5GHWH6 F4Lm5eaAlx8gB+pIu2rUtKt7eCxtpNMit2mSNrg+VhJdmGOZzQTtVnVnbbtx 05ZoXXm0tePLl/8AS47zOPtkLVm2e8Erjnu7IRHa1sT3GnEK0UHvTu1by92k juLa1kcSx8sp6oSONMrQGgjzphmeTr1nwpztRmfbRRAZJIy7NO1zg94Oxrsd jeBIGaZ3rSPdyuJ+tFzazWdzLa3Dcs0Lix4rXEeVchR0egft2+01bVuT4Ke3 l51i5+Zb7TfqWz7j+CHt5edX0FjQhCgFgGpbZO2ct/WA6ltl8kzvrQMG8a8X WWgafvCv0p6zTJHtDhICDxCqlsnLWnj23uNZnCPyPd6rSeRXvdC+kmsO6SVE tocAdpidsPmOCq3dpbZpY1pe5+OamwbNg2qQ0e7h0+4NyHPEpaWO61ji1wPB Ruxa1s5yx5fHtM63W5jRo+sc3i8gVT3m1Pd2SW3fPK69msi7LZRfhOeT+bJw YjEBOHb2sMRbE+KIkUz0eXDgqA4UVPfBZQukIm66riQQ12I5KJ8OWmlz1m3w ZXl5LfXUt1NTrpnl76Cgx4AOIJEKSZaRXZOUlgZ5Mu3l2pC8tI7UhucmQ0OU 02HGuCz3TOHp+rfs78Y1NWn9s0+ULatx/BD28vOsVqOtafKFte5Hgh7eXnWv RhYkIQoBYDqX53bHnK35fP8AqD8z5gMQJTX0lAzc6rWjiFF62edjcjJHNZ90 EgLyNnWODK5SdleEpY2MnGFLj1a1m3Ouf4IGWU7XuPnK5qeMpx3N/C5ddxP3 kzDt3vua1PGvKlP2acHEAuI5EpLpcbBUPcTyBO6NfVv7IypRVPDYHgf9C4ls zEwvc7AbMNpTMZum3sbg9IHyhbbuR4J/Gk51iQBqFtW4crJdAD2GreukFfOF WVlQhCAWC3NtE+6mqD+I7YfKVvSzm9/671MSyS2tzDM1znODX5o3UOP6w+lB Sm6bC7Y97fQf0J02ItaAXhxH2i3Hz0cpt+5+8UJA7mZMK1Y+M/7gmz9C1pta 2FxhtpG4j6AlkvJrvvr/AJuEU5jhskYOVhP+9cEyD85g/hH4k+k07UW+taTj ljf8KRdpmpbe5z0PD1T6enKnbr7Nfb5P2psJJmnCdv8A8v0lddbO/bOD/Cb8 SVGl6i40FpOT2T/hTiHQ9ZeehYXDv4T/ANCduvtF+3yftt8kYYHP9aX0RgfW nB0q1mIMzpJMuwAtYP8AS1SNpu5rrsRYygD7wDPfLVKQbq628AugEdcOm9uH LlJVxrOJGL5PJel2titO06wi9S3FeNxLveK0XchoboTQAGjrZMAKDaFGR7j3 cn49zHHtqGNL+TbkVm0jS49KsxaRyOlaHF2ZwANXciWsyXJ+hCFGghCEAhCE AhCEAhCEAhCEAhCEAhCEH//Z --= Multipart Boundary 0506021742-- From glingl@aon.at Mon May 6 17:37:43 2002 From: glingl@aon.at (Gregor Lingl) Date: Mon, 6 May 2002 18:37:43 +0200 Subject: [Idle-dev] IDLE has problem with Umlaute References: <981558358.1018888807@muon> Message-ID: <002c01c1f51c$58a48170$1615a8c0@mega> Hi! In my class (at a Viennese Highschool) there occured the following problem, which - if not solved - would enforce a seriously restricted use of IDLE: We use Python2.2. When trying to save the following fancy program print "Größtes Problem: Umlaute" from an IDLE editor window, I got the error messages: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1292, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\Python22\Tools\idle\IOBinding.py", line 154, in writefile f.write(chars) UnicodeError: ASCII encoding error: ordinal not in range(128) So IDLE seems to prohibit the use of "ÄÖÜäöüß" . For German native speakers i consider this to be a serious drawback, especially when using it with students. Shortly I'd prefer to teach programming instead of teaching to avoid Umlaute. As far as I remember we had previous Python versions, which did NOT show this 'feature'. ================================================= !!! Is there a patch to repair this problem? !!! ================================================= Wouldn't it be a nice idea to have an IDLE, which is able to digest German texts at the EURO-Python-Conference? a bit desparately Gregor From dyoo@hkn.eecs.berkeley.edu Mon May 6 19:12:34 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Mon, 6 May 2002 11:12:34 -0700 (PDT) Subject: [Idle-dev] Re: [Tutor] IDLE has problem with Umlaute In-Reply-To: <002c01c1f51c$58a48170$1615a8c0@mega> Message-ID: > print "Gr=F6=DFtes Problem: Umlaute" > > from an IDLE editor window, I got the error > messages: > > > >>> Exception in Tkinter callback > Traceback (most recent call last): > File "C:\Python22\lib\lib-tk\Tkinter.py", line 1292, in __call__ > return apply(self.func, args) > File "C:\Python22\Tools\idle\IOBinding.py", line 136, in save_as > if self.writefile(filename): > File "C:\Python22\Tools\idle\IOBinding.py", line 154, in writefile > f.write(chars) > UnicodeError: ASCII encoding error: ordinal not in range(128) > > So IDLE seems to prohibit the use of "=C4=D6=DC=E4=F6=FC=DF" . For German= native > speakers i consider this to be a serious drawback, especially when > using it with students. Hi Gregor, It's a unicode encoding thing: you'll need to set the 'default encoding' scheme of your system to 'iso-8859-1', which is the encoding scheme for Central Europe. For example: ### >>> s =3D "" >>> s '\xc4\xd6\xdc\xe4\xf6\xfc\xdf' >>> unicode(s) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) >>> unicode(s, 'iso-8859-1') u'\xc4\xd6\xdc\xe4\xf6\xfc\xdf' ### There should be a way to set this up site-wide so that all of Python knows that it should use the Central European encoding... checking... Ah! http://www.faqts.com/knowledge_base/view.phtml/aid/11712 mentions something about this, but I don't see sys.setdefaultencoding() in my interpreter session... Doh. That's because site.py removes sys.setdefaultencoding() after Python loads up: ### site.py # # Remove sys.setdefaultencoding() so that users cannot change the # encoding after initialization. The test for presence is needed when # this module is run as a script, because this code is executed twice. # if hasattr(sys, "setdefaultencoding"): del sys.setdefaultencoding ### So you'll need to call sys.setdefaultencoding() within sitecustomize.py to have this work sitewide. Hope this helps. Good luck! From hernan@orgmf.com.ar Mon May 6 19:19:05 2002 From: hernan@orgmf.com.ar (Hernan Martinez Foffani) Date: Mon, 6 May 2002 20:19:05 +0200 Subject: [Idle-dev] Re: [Tutor] IDLE has problem with Umlaute In-Reply-To: Message-ID: See FAQ 4.102 at http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.102.htp Basically you just create a file sitecustomize.py under site-packages directory with the following content: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] if encoding != "ascii": import sys sys.setdefaultencoding(encoding) Beware that if you do that the python programs you write may not be portable between sites with different encodings!!!!!!!! Regards, -Hernan From altis@semi-retired.com Mon May 6 22:19:40 2002 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 6 May 2002 14:19:40 -0700 Subject: [Idle-dev] FW: [Pythoncard-users] codeEditor sample Message-ID: Hi, this is just an FYI that PythonCard http://pythoncard.sourceforge.net/ now has its own editor, based on the wxStyledTextCtrl (wxSTC) in wxPython. We will be leveraging IDLE and Pythonwin code where appropriate, but since the focus is on a wxPython code base rather than tkinter, I'm not sure how much source will make sense to flow back into IDLE. Most of the heavy lifting is actually done by wxSTC, so a lot of the basic editor logic required for IDLE is not used at all. Of course, any bug fixes that impact IDLE will be reported. I'm subscribed to idle-dev, but will be traveling the latter part of May so I probably won't be paying much attention the list until June. There should be some more improvements to codeEditor this week in cvs as well as a new PythonCard release before the end of the week and that release will include codeEditor. The announcement I made to the PythonCard-users list is below. The codeEditor wiki page is at: http://wiki.wxpython.org/index.cgi/PythonCardEditor ka --- Kevin Altis altis@semi-retired.com -----Original Message----- From: pythoncard-users-admin@lists.sourceforge.net [mailto:pythoncard-users-admin@lists.sourceforge.net]On Behalf Of Kevin Altis Sent: Monday, May 06, 2002 12:46 PM To: pythoncard-Users Subject: [Pythoncard-users] codeEditor sample Ladies and gentlemen, I present the codeEditor sample. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp e/samples/codeEditor/ Much like the resourceEditor sample, this will become a core element of PythonCard and in the meantime is a workable sample. This is not intended to be a full-featured generic editor. If you are already using vi(m), Emacs, Boa, IDLE, or one of the many editors listed at http://www.python.org/editors/ then there is no particular reason you need to switch to codeEditor unless you want to. What codeEditor will do is provide a free and integrated editor in PythonCard designed to edit Python source code at least as well as IDLE and Pythonwin. There will be a tight integration with the shell and resourceEditor, features such as code completion, tooltips, module browsing, running and debugging Python scripts should eventually be supported so this isn't going to be a toy editor. I'm guessing that we'll end up with a merge of resourceEditor and codeEditor eventually to give us an integrated development environment (IDE). The code is based on the textEditor sample. Last Friday after an email exchange I decided I would rather see how difficult it would be to jump start this rather than writing my umpteenth Mac OS X test script for the week. I copied the textEditor sample, created a new CodeEditor component that wraps the wxStyledTextCtrl (wxSTC) and fifteen minutes later the first version was working. Patrick rolled some of the PyCrust code into the component. With some more input from Patrick and Neil and some tweaking the editor is already pretty usable, though many features are still missing. I'm already starting to use it myself for all my Python editing. This is known in the trade as "eating your own dog food" and it is a principle I agree with because developers should suffer the same code as their users. codeEditor already supports the Scriptlets addition I made to the textEditor sample. That means you can extend codeEditor functionality and manipulate the contents of the codeEditor window by writing and using Python Scriptlets. Pretty cool. If you have a script idea or code (if you can do it in the shell it can be a scriptlet) you would like added to the standard distribution, just post it to the list. A lot of features will probably get written and tested as scriptlets before being rolled into the main codeEditor module. http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1181106 I already updated findfiles so that if you double-click on a Python script (.py or .pyw) in the results list it will open the codeEditor sample instead of the textEditor sample. Some of findfiles will probably get rolled into codeEditor. What I don't want to do is make codeEditor a bloated editor with too many options and UI elements so that it no longer fulfills its core purpose of editing Python scripts. Your input, code contributions, etc. as it progresses will be appreciated. I created a codeEditor wiki page to keep track of issues: http://wiki.wxpython.org/index.cgi/PythonCardEditor Note that if you are going to use codeEditor for your own scripts you should be aware that it currently only supports tab stops of four spaces as Guido recommends. It does not interpret or convert tabs. All of the PythonCard source uses spaces. More elaborate tab support will be added. As always with something like this, make backups of important files in case a bug in codeEditor corrupts a source file. wxSTC does not work correctly on OS X yet, so it won't run on OS X just like the shell doesn't work on OS X, yet. ka _______________________________________________ Pythoncard-users mailing list Pythoncard-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pythoncard-users From michael.williams@st-annes.oxford.ac.uk Wed May 8 21:10:57 2002 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Wed, 8 May 2002 21:10:57 +0100 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers Message-ID: <20020508201057.GJ3537@st-annes.oxford.ac.uk> Dear All, Here in the Department of Physics at Oxford University we're attempting to replace the current undergraduate programming course (which is currently taught using Pascal) with a more modern and user friendly one. We're running trials on a number of languages over the next couple of months and Python seems to be the front-runner. Idlefork appears to be the most suitable frontend for our purposes and we have been using it without problem during the development of the course. However, we have found a serious problem since we tried to run it in multi-user environment. We do not have individual workstations but rather a SunRay system which is basically a single machine (running Solaris 5.7 in our case[0]) driving out multiple xserver displays to ~20 SunRay clients (which are essentially dumb terminals). [0] This is *not* a Solaris specific problem though! The first user to run idlefork gets on fine. However, the next user, who is at a different terminal, which recieves the output of a different xserver instance (i.e. has a different $DISPLAY), cannot get idlefork at their own terminal. If they run the idle script at an xterm there is a brief pause and then the program appears to have finished--the worst kind of error message. However, the xserver on which idlefork was first run now has another idlefork window! So the first person has a window they didn't ask for, and the second has no window at all! If the first person the does File->Exit one either window both windows disappear. This can be verified by those of you running Linux systems by starting up one xserver in the usual way. Then, at a Linux console (which for example Ctrl-Alt-F2 will give you on most setups) starting up another xserver (it makes no difference whether you are the same user or a different one). On my Debian system (and I believe on most others) this is done using the command "startx -- :1". You can then swap between the two xservers using Ctrl-Alt-F7 and Ctrl-Alt-F8. Run idlefork on the first xserver (:0), and then swap to the other (:0) and run it again. You will get no idlefork but (:1) will have a new window. I don't know if this is related but running idlefork with the -v switch the second time gives the following error message: [willmsmj@rayleigh:~]$ idle -v Traceback (most recent call last): File "/usr/local/bin/idle", line 4, in ? PyShell.main() File "/usr/local/bin/../packages/idlefork-0.8.1/PyShell.py", line 746, in __init__ sys.stderr.write("Error: %s\n" % str(msg)) TypeError: __str__ returned non-string (type instance) Surely the right behaviour would be to open up a new instance of idlefork on the xserver from which it was called? Indeed, this is the behaviour of Idle as bundled with Python in the Tools/ directory at present. The problem is present in both the current CVS version and 0.8.1.tar.gz available from Sourceforge. We would really like to avoid using the basic Idle as we have to teach computer programming in just one day (!) and believe the idlefork interface is much more intuitive. If anyone has any further questions about our setup (although we do not believe this is related) feel free to ask. We're running Python2.2.1 by the way. Here's hoping there's a workaround or a one-liner! -- Michael Williams Department of Physics | University of Oxford michael.williams@st-annes.oxford.ac.uk From guido@python.org Wed May 8 21:29:37 2002 From: guido@python.org (Guido van Rossum) Date: Wed, 08 May 2002 16:29:37 -0400 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: Your message of "Wed, 08 May 2002 21:10:57 BST." <20020508201057.GJ3537@st-annes.oxford.ac.uk> References: <20020508201057.GJ3537@st-annes.oxford.ac.uk> Message-ID: <200205082029.g48KTbS02928@odiug.zope.com> > The first user to run idlefork gets on fine. However, the next user, > who is at a different terminal, which recieves the output of a > different xserver instance (i.e. has a different $DISPLAY), cannot > get idlefork at their own terminal. Could it be that the RPC mechanism used to communicate between IDLE and its child process (where code is executed) uses a constant port? --Guido van Rossum (home page: http://www.python.org/~guido/) From elguavas@users.sourceforge.net Thu May 9 05:02:37 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 09 May 2002 14:02:37 +1000 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: <200205082029.g48KTbS02928@odiug.zope.com> References: <20020508201057.GJ3537@st-annes.oxford.ac.uk> <200205082029.g48KTbS02928@odiug.zope.com> Message-ID: <1020916958.4563.50.camel@oberon> Hello Michael. Guido van Rossum wrote: > > The first user to run idlefork gets on fine. However, the next user, > > who is at a different terminal, which recieves the output of a > > different xserver instance (i.e. has a different $DISPLAY), cannot > > get idlefork at their own terminal. > > Could it be that the RPC mechanism used to communicate between IDLE > and its child process (where code is executed) uses a constant port? Indeed, this may be the case. It's likely that the reason regular python idle works fine in this case is that it contains no rpc mechanism at all. (Python code executed from python idle is executed in idle's own process, which is one of the limitations that vpython-idle/idlefork originally set out to address, and is the only reason why idlefork uses an rpc scheme.) So the reason why you get no error message when the second xterm starts idlefork would be that idlefork (which is running on the server but using the first xterm as its display) thinks there is no error; it is simply being asked by the second xterm to create a new instance, which the idlefork process running on the server responds to by saying, "idlefork is already using my fixed port (yes Guido, idlefork's current rpc uses one fixed port only) so I will create a new window in the running instance", which happens to be the one which is using the first xterm as its display. So idlefork thinks it has done the right thing, which of course in the case of running on multiple x displays it has not. Unfortunately I am interstate on a contract at the moment, so I cannot look into this in detail, but I will poke around and see if my assumption is correct when I return home (hopefully next week if there are no more delays at this site). Since I am the only active idlefork developer that may mean that there won't be a definitive answer on this until then, unless __are you listening guys__ someone else reading this list with knowledge of the idlefork codebase looks into this before then. Problems with the current rpc implementation in idlefork, such as this one where it pretty much assumes that idlefork is only running on one x display, and some others to do with debugging problems and other things, are the reason why the next major step for idlefork (after the config re-implementation is finished) is for the rpc mechanism to be completely re-developed. (I've been looking for a second interested developer to work on this aspect of idlefork for almost a year now, possible implementations even exist, they just need to be tested and the best one grafted in.) So as I see it, and if my assumption that Guido is right about the nature of the problem is correct, I can think of a couple of possible courses of action you can take. One is, depending on your reasons for preferring idlefork's behaviour to idle's for your installation, it may be possible to set up python idle in such a way that it is acceptable for your purposes until idlefork's rpc mechanism is re-developed. Another possibility is that the idlefork 0.8.1 (I wouldn't recommend using cvs idlefork in a production environment, as with all development software it is in a constant state of buggy flux) version may be able to be somehow patched to work around your problem in the short term, with the new rpc implementation being the long term fix. If the second suggestion turns out to be the necessary one, and no helpful person jumps in to take a look at this for me ( __hint, hint, other idle-dev readers...__ :) then I will have a look at it as soon as I am able. Regards, Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From michael.williams@st-annes.oxford.ac.uk Thu May 9 12:58:14 2002 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Thu, 9 May 2002 12:58:14 +0100 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: <1020916958.4563.50.camel@oberon> References: <20020508201057.GJ3537@st-annes.oxford.ac.uk> <200205082029.g48KTbS02928@odiug.zope.com> <1020916958.4563.50.camel@oberon> Message-ID: <20020509115810.GO3537@st-annes.oxford.ac.uk> On Thu, May 09, 2002 at 02:02:37PM +1000, Stephen M. Gava wrote: > Guido van Rossum wrote: > > > The first user to run idlefork gets on fine. However, the next > > > user, who is at a different terminal, which recieves the output of > > > a different xserver instance (i.e. has a different $DISPLAY), > > > cannot get idlefork at their own terminal. > > > > Could it be that the RPC mechanism used to communicate between IDLE > > and its child process (where code is executed) uses a constant port? > So as I see it, and if my assumption that Guido is right about the > nature of the problem is correct, I can think of a couple of possible > courses of action you can take. One is, depending on your reasons for > preferring idlefork's behaviour to idle's for your installation, it > may be possible to set up python idle in such a way that it is > acceptable for your purposes until idlefork's rpc mechanism is > re-developed. Another possibility is that the idlefork 0.8.1 (I > wouldn't recommend using cvs idlefork in a production environment, as > with all development software it is in a constant state of buggy flux) > version may be able to be somehow patched to work around your problem > in the short term, with the new rpc implementation being the long term > fix. If the second suggestion turns out to be the necessary one, and > no helpful person jumps in to take a look at this for me ( __hint, > hint, other idle-dev readers...__ :) then I will have a look at it as > soon as I am able. The reason we particularly like(d!) idlefork compared to idle was: - The simplification of the pull down menus. In idle they are rather crufty for our purposes. Presumably this wouldn't be too hard to fix with a hacky solution for the time being. If someone could point me to the file we need to look at to fiddle with the contents of the menus I'll even have a go myself. - At present the way one would "run" a saved module in idle is by going to the Edit (!) menu (which is a pretty long menu already and selecting "import module". We were hoping to avid the complications of module importing in our short course -- we don't expect any students to get beyond simple one module programs in the two days they have so I guess we'd like to rename this menu item. - Probably the most important thing though, is where the programs output goes. In idle it is directed to the Python Shell window. This potentially leads to conceptual confusion for students (we were already wary of telling them about the shell at all). Is there an easy way to direct output to a new window as it is done in idlefork. - And it would be nice to F5/"import module/"run" a module without saving it. What idlefork presumably does is save somewhere in /tmp. So that's what we want! Unfortunatly our trial starts next Tuesday. We had been quite happily testing the system without trouble until my supervisor and I coincidentally tried to run idlefork at the same time, which kind-of explains the appallingly late discovery of this problem with our course (it's basically my own fault!) We need a stop gap solution for next week. idle as it stands will probably do the job. The other possibity is to remove the use of the interactive environment from the course entirely (the course teaches basic procedural programming) and use an editor like SciTe which directs output to a separate window and has no integrated support for the Python Shell. Unfortunately SciTe doesn't seem to do the semi-automatic indentation of idle(fork) which is potentially a big problem. So if anyone has any suggestions of how we could solve the four problems preventing us from using the core idle, or could even recommend another Python-friendly editor (*not* Vim or Emacs!), ideally which integrates the shell I'm all ears! Thanks for the prompt replies though guys. I might be working on this course over the summer and be being paid by the department (I'm doing this as my Masters project but if it actually gets used then I may well get some cash for it) which will allow me to spend a bit more time actually coding. I'm a reasonably competent Python developer so hope to be able to offer help or have ago at the reimplementation of the RPC mapping so we can use idlefork on "real" first years next October. But we need a solution for next week... -- Michael From basherwo@unity.ncsu.edu Thu May 9 14:41:19 2002 From: basherwo@unity.ncsu.edu (Bruce Sherwood) Date: Thu, 09 May 2002 08:41:19 -500 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: <20020509115810.GO3537@st-annes.oxford.ac.uk> Message-ID: <200205091241.g49CfKj24056@uni02mr.unity.ncsu.edu> > - And it would be nice to F5/"import module/"run" a module without > saving it. What idlefork presumably does is save somewhere in /tmp. Indeed, every time you run (F5), idlefork saves the current file (somewhere). Once you do an actual named save operation, later saves go to that named file. The huge advantage is that if there is a crash of any kind, you are very unlikely to lose any work. The importance is that novices aren't likely to think of saving their work periodically. In two years of class use ONE student ONCE lost some edits! At the same time, idlefork supports infinite un-dos. My only regret is that I personally know far too little to help you with your technical problem. But here's an uninformed thought of a possible temporary work-around: Could you set up multiple copies of Python and idlefork for your multiple users? Bruce Sherwood Joining the NCSU Dept. of Physics June 1, 2002 From guido@python.org Thu May 9 13:59:01 2002 From: guido@python.org (Guido van Rossum) Date: Thu, 09 May 2002 08:59:01 -0400 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: Your message of "Thu, 09 May 2002 12:58:14 BST." <20020509115810.GO3537@st-annes.oxford.ac.uk> References: <20020508201057.GJ3537@st-annes.oxford.ac.uk> <200205082029.g48KTbS02928@odiug.zope.com> <1020916958.4563.50.camel@oberon> <20020509115810.GO3537@st-annes.oxford.ac.uk> Message-ID: <200205091259.g49Cx1a02341@pcp742651pcs.reston01.va.comcast.net> > We need a stop gap solution for next week. idle as it stands will > probably do the job. The problem is indeed that all instances use the same port. This is determined by the line default_port = 0x1D1E # "IDlE" in the file protocol.py. If you could make this initialized from an environment variable, e.g. default_port = 0x1D1E # "IDlE" p = os.environ.get("PORT") if p: default_port = int(p) then you can give each student a personalized environment variable. That's the best I can think of rigt now. --Guido van Rossum (home page: http://www.python.org/~guido/) From michael.williams@st-annes.oxford.ac.uk Thu May 9 14:59:33 2002 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Thu, 9 May 2002 14:59:33 +0100 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: <200205091259.g49Cx1a02341@pcp742651pcs.reston01.va.comcast.net> References: <20020508201057.GJ3537@st-annes.oxford.ac.uk> <200205082029.g48KTbS02928@odiug.zope.com> <1020916958.4563.50.camel@oberon> <20020509115810.GO3537@st-annes.oxford.ac.uk> <200205091259.g49Cx1a02341@pcp742651pcs.reston01.va.comcast.net> Message-ID: <20020509135933.GB7206@st-annes.oxford.ac.uk> On Thu, May 09, 2002 at 08:59:01AM -0400, Guido van Rossum wrote: > > We need a stop gap solution for next week. idle as it stands will > > probably do the job. > > The problem is indeed that all instances use the same port. This is > determined by the line > > default_port = 0x1D1E # "IDlE" > > in the file protocol.py. If you could make this initialized from an > environment variable, e.g. > > default_port = 0x1D1E # "IDlE" > p = os.environ.get("PORT") > if p: default_port = int(p) > > then you can give each student a personalized environment variable. > > That's the best I can think of rigt now. A quick test suggests that works and may be just the temporary solution we are looking for. Thanks very much! Is there a particular range we should use for the PORT variable? Over 1024 for example? -- Michael From guido@python.org Thu May 9 22:21:05 2002 From: guido@python.org (Guido van Rossum) Date: Thu, 09 May 2002 17:21:05 -0400 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: Your message of "Thu, 09 May 2002 14:59:33 BST." <20020509135933.GB7206@st-annes.oxford.ac.uk> References: <20020508201057.GJ3537@st-annes.oxford.ac.uk> <200205082029.g48KTbS02928@odiug.zope.com> <1020916958.4563.50.camel@oberon> <20020509115810.GO3537@st-annes.oxford.ac.uk> <200205091259.g49Cx1a02341@pcp742651pcs.reston01.va.comcast.net> <20020509135933.GB7206@st-annes.oxford.ac.uk> Message-ID: <200205092121.g49LL5905553@odiug.zope.com> > A quick test suggests that works and may be just the temporary solution > we are looking for. Thanks very much! Is there a particular range we > should use for the PORT variable? Over 1024 for example? I believe ports are in the range 1-65K, but 1-1023 are reserved for root. I don't know what other services are running on your system, so I can't really recommend a specific range of ports; ask your sysadmin, or use netstat to find out. I often use numbers between 7000 and 8000 (exclusive) and that usually seems to work. You could also try 50000-60000. --Guido van Rossum (home page: http://www.python.org/~guido/) From michael.williams@st-annes.oxford.ac.uk Fri May 10 16:13:51 2002 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Fri, 10 May 2002 16:13:51 +0100 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: References: <20020509174625.GI7206@st-annes.oxford.ac.uk> Message-ID: <20020510151350.GA912@st-annes.oxford.ac.uk> On Fri, May 10, 2002 at 09:05:14AM +0200, Hernan Martinez Foffani wrote: > Your solution will work provided you don't have any service listening > above the port 4096. You can't restrain the OS the range of PIDs it > generates. Besides many processes that use sockets don't register > themself in /etc/services. As Guido said, the netstat may also help > you. Yes. We had a good look at ports in use before deciding on that solution. With the way Solaris uses ports (i.e. almost at random!) we may still get problems but it does appear to work. > An alternative that may interest you which does not differ too much > what you did, is to add the user id of each student to 4096 instead. > > This has the problem that a user can't have more that one idle running > at the same time. We did consider getuid, but rejected it for precisely that reason. It seemed that although having more than one instance running *might* be confusing, a user who types idlefork a second time most probably wants a second instance, so that's what they'll get. For anyone who's interested, we wrote the script in Python. It was our sysadmin's first look at it and he seemed to like it. We'd spent several minutes looking through man pages for the syntax in sh or csh until I said let's just use python.os. Here's what we came up with--hardly rocket science but it works: import os thispid = os.getpid() portnumber = thispid + 4096 os.putenv("IDLEPORT", str(portnumber)) os.system("/usr/local/bin/idle-0.8.1") -- Michael From mats@laplaza.org Fri May 10 05:29:42 2002 From: mats@laplaza.org (Mats Wichmann) Date: Thu, 09 May 2002 21:29:42 -0700 Subject: [Idle-dev] Serious problems getting idlefork to display on multiple xservers In-Reply-To: <20020509135933.GB7206@st-annes.oxford.ac.uk> References: <200205091259.g49Cx1a02341@pcp742651pcs.reston01.va.comcast.net> <20020508201057.GJ3537@st-annes.oxford.ac.uk> <200205082029.g48KTbS02928@odiug.zope.com> <1020916958.4563.50.camel@oberon> <20020509115810.GO3537@st-annes.oxford.ac.uk> <200205091259.g49Cx1a02341@pcp742651pcs.reston01.va.comcast.net> Message-ID: <5.1.0.14.1.20020509202633.0203ba08@204.151.72.2> At 02:59 PM 5/9/2002 +0100, Michael Williams wrote: >On Thu, May 09, 2002 at 08:59:01AM -0400, Guido van Rossum wrote: >> > We need a stop gap solution for next week. idle as it stands will >> > probably do the job. >> >> The problem is indeed that all instances use the same port. This is >> determined by the line >> >> default_port = 0x1D1E # "IDlE" >> >> in the file protocol.py. If you could make this initialized from an >> environment variable, e.g. >> >> default_port = 0x1D1E # "IDlE" >> p = os.environ.get("PORT") >> if p: default_port = int(p) >> >> then you can give each student a personalized environment variable. >> >> That's the best I can think of rigt now. > >A quick test suggests that works and may be just the temporary solution >we are looking for. Thanks very much! Is there a particular range we >should use for the PORT variable? Over 1024 for example? User-chosen ports should be over some number that's around 32k. There's a chart that shows what the different port ranges are blocked off for. So the latter range Guido suggests (50000 to 60000) is a good one. I'm wondering if, longer-term, this whole scheme is going to be clean for people who like to use a secure (ssh) tunnel for their remote displays. Maybe there's no impact, I'd actually have to stop and think (gasp). From noreply@sourceforge.net Sun May 12 15:15:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 07:15:33 -0700 Subject: [Idle-dev] [ idlefork-Bugs-475984 ] Usage message gets lost Message-ID: Bugs item #475984, was opened at 2001-10-29 13:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=475984&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Usage message gets lost Initial Comment: When idle is given the wrong command line arguments, it prints a usage message on stdout and exits. This works in the IDLE version in the Python CVS repository. But the idlefork IDLE in this case briefly brings up a window, and immediately removes it again, before I can read anything. I'm guessing the initiailization order has been changed so that it prints the usage message to an output window. This is on Linux, but I bet it's also on Windows. ---------------------------------------------------------------------- Comment By: Chui Tey (teyc) Date: 2002-05-12 14:15 Message: Logged In: YES user_id=29167 I cannot reproduce this behaviour on the current version in the CVS? Can anyone else confirm that it's been fixed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=475984&group_id=9579 From noreply@sourceforge.net Sun May 12 15:53:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 07:53:54 -0700 Subject: [Idle-dev] [ idlefork-Bugs-475984 ] Usage message gets lost Message-ID: Bugs item #475984, was opened at 2001-10-29 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=475984&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Usage message gets lost Initial Comment: When idle is given the wrong command line arguments, it prints a usage message on stdout and exits. This works in the IDLE version in the Python CVS repository. But the idlefork IDLE in this case briefly brings up a window, and immediately removes it again, before I can read anything. I'm guessing the initiailization order has been changed so that it prints the usage message to an output window. This is on Linux, but I bet it's also on Windows. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-12 10:53 Message: Logged In: YES user_id=6380 Yup, sure looks like it's fixed. ---------------------------------------------------------------------- Comment By: Chui Tey (teyc) Date: 2002-05-12 10:15 Message: Logged In: YES user_id=29167 I cannot reproduce this behaviour on the current version in the CVS? Can anyone else confirm that it's been fixed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=475984&group_id=9579 From michael.williams@st-annes.oxford.ac.uk Sun May 12 17:38:41 2002 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Sun, 12 May 2002 17:38:41 +0100 Subject: [Idle-dev] Changing to -Qnew sitewide Message-ID: <20020512163840.GF3561@st-annes.oxford.ac.uk> I just posted this to comp.lang.python http://groups.google.com/groups?dq=&hl=en&group=comp.lang.python&selm=ablhh9%24ii04e%241%40ID-96223.news.dfncis.de (watch those line wraps!) To summarise, what we want to do is apply the -Qnew switch to idlefork's interactive shell, and to all the modules it is used to run. I got this reply (although it hasn't shown up on Google yet): On Sun, 12 May 2002 13:16:49 +0100, Terry Reedy wrote: > I would aim at creating an 'idlepy' command which would bring up > python in -Qnew mode (assuming idlefork code itself is 'Qnew clean') > with a possibly-patched idlefork in mode in which *it* puts the magic > incantation at the start of every program. Automate the repetitive. > > I know nothing of idlefork at this time and do not know if it > currently has a switch to do this, but it certainly ought to. I would > certainly like a version that would do so. I suspect others would > also. Could someone suggest how I might do this? -- Michael From bas@andrew.cmu.edu Sun May 12 18:55:44 2002 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Sun, 12 May 2002 13:55:44 -0400 Subject: [Idle-dev] -Qnew default Message-ID: <3304495128.1021211744@HYPERON.REM.CMU.EDU> Some months ago I experimented with making -Qnew the default when running from idlefork, and it mostly worked, though as I remember it there was a problem with a pre-release version of Python 2.2, which has probably been fixed by now. In ExecBinding.py, make the indicated change: def run_complete_script_event(self, event): filename = self.getfilename() if not filename: return filename = os.path.abspath(filename) self.stopProgram() self.commands = [ ('run', filename) ] waiting_for_loader.append(self) ## spawn.spawn( pyth_exe, load_py ) ## The following makes all programs started from IDLE use true division: spawn.spawn( pyth_exe, "-Qnew", load_py ) Bruce Sherwood From michael.williams@st-annes.oxford.ac.uk Sun May 12 19:01:49 2002 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Sun, 12 May 2002 19:01:49 +0100 Subject: [Idle-dev] Re: -Qnew default In-Reply-To: <3304495128.1021211744@HYPERON.REM.CMU.EDU> References: <3304495128.1021211744@HYPERON.REM.CMU.EDU> Message-ID: <20020512180149.GB5574@st-annes.oxford.ac.uk> On Sun, May 12, 2002 at 01:55:44PM -0400, Bruce Sherwood wrote: > Some months ago I experimented with making -Qnew the default when running > from idlefork, and it mostly worked, though as I remember it there was a > problem with a pre-release version of Python 2.2, which has probably been > fixed by now. In ExecBinding.py, make the indicated change: > > def run_complete_script_event(self, event): > filename = self.getfilename() > if not filename: return > filename = os.path.abspath(filename) > > self.stopProgram() > > self.commands = [ ('run', filename) ] > waiting_for_loader.append(self) > ## spawn.spawn( pyth_exe, load_py ) > ## The following makes all programs started from IDLE use true division: > spawn.spawn( pyth_exe, "-Qnew", load_py ) That works for modules but not the interactive shell. Any ideas? -- Michael From guido@python.org Sun May 12 21:49:17 2002 From: guido@python.org (Guido van Rossum) Date: Sun, 12 May 2002 16:49:17 -0400 Subject: [Idle-dev] Re: -Qnew default In-Reply-To: Your message of "Sun, 12 May 2002 19:01:49 BST." <20020512180149.GB5574@st-annes.oxford.ac.uk> References: <3304495128.1021211744@HYPERON.REM.CMU.EDU> <20020512180149.GB5574@st-annes.oxford.ac.uk> Message-ID: <200205122049.g4CKnHL00429@pcp742651pcs.reston01.va.comcast.net> > That works for modules but not the interactive shell. Any ideas? Start idle itself with "python -Qnew". --Guido van Rossum (home page: http://www.python.org/~guido/) From teyc@users.sourceforge.net Wed May 15 00:45:16 2002 From: teyc@users.sourceforge.net (Chui Tey) Date: Tue, 14 May 2002 16:45:16 -0700 Subject: [Idle-dev] CVS: idle RemoteInterp.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv13071 Modified Files: RemoteInterp.py Log Message: Fixed bug: Split RPC message into two parts instead of three Index: RemoteInterp.py =================================================================== RCS file: /cvsroot/idlefork/idle/RemoteInterp.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** RemoteInterp.py 4 Jul 2001 03:15:10 -0000 1.2 --- RemoteInterp.py 14 May 2002 23:45:14 -0000 1.3 *************** *** 122,126 **** seqno = self.decode_seqno(msg[:self.SEQNO_ENC_LEN]) msg = msg[self.SEQNO_ENC_LEN:] ! parts = msg.split(" ", 2) if len(parts) == 1: cmd = msg --- 122,126 ---- seqno = self.decode_seqno(msg[:self.SEQNO_ENC_LEN]) msg = msg[self.SEQNO_ENC_LEN:] ! parts = msg.split(" ", 1) if len(parts) == 1: cmd = msg From jjc@honors.montana.edu Wed May 15 15:42:13 2002 From: jjc@honors.montana.edu (Josh Cogliati) Date: Wed, 15 May 2002 08:42:13 -0600 Subject: [Idle-dev] [childoflight55@hotmail.com: I have a question about Python version 2.2] Message-ID: <20020515084212.A1001@localhost> Hello, I periodically recieve messages like the following: ----- Forwarded message from Brett Gailey ----- Envelope-to: jjc@localhost X-Originating-IP: [24.51.244.64] From: "Brett xxxxx" To: jjc@honors.montana.edu Subject: I have a question about Python version 2.2 Date: Wed, 15 May 2002 03:58:32 +0000 X-OriginalArrivalTime: 15 May 2002 03:58:39.0952 (UTC) FILETIME=[CC1A4500:01C1FBC4] X-UIDL: 7C`!!05]!!,35"!#=Z"! Hello, and Im sorry to bother you like this. I recently aquired Python and I was interested in programming, even if it is in the simplist form. Im sure my question is stupid and you are probably getting millions of these a day. I was reading your outline for Python and I just saved "Print 'Hello, world!'" and when I tried to use "run script" and it save "The buffer for PythonShell is not saved. Please save it First!". I honestly have no idea what to do. I would be much appreciative if you could help me out with this. Again Im sorry for the inconvience, I am thankful for your time. xxxxx ----- End forwarded message ----- I think that that error message should: 1. Change it to be more friendly to newbie programmers. 2. Include a button like "Save" that directly takes the user to save dialog box. Thanks. -- Josh Cogliati jjc@honors.montana.edu This message created in Linux, the choice of a GNU generation. From noreply@sourceforge.net Mon May 20 03:37:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:37:30 -0700 Subject: [Idle-dev] [ idlefork-Bugs-441475 ] Wrong initial numbers in status bar. Message-ID: Bugs item #441475, was opened at 2001-07-16 03:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441475&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong initial numbers in status bar. Initial Comment: When IDLE is run (on Win98, at least) it displays incorrect line and column numbers in the status bar - lin: 1 col: 3 should be lin: 7 col: 4. As soon as the cursor is moved the status bar is updated with the proper information. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:37 Message: Logged In: YES user_id=75867 Can anyone with win98 still reproduce this problem? I think it may have been fixed ages ago. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441475&group_id=9579 From noreply@sourceforge.net Mon May 20 03:40:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:40:13 -0700 Subject: [Idle-dev] [ idlefork-Bugs-486001 ] Must logout to re-use idle... Message-ID: Bugs item #486001, was opened at 2001-11-28 01:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486001&group_id=9579 Category: None Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: Must logout to re-use idle... Initial Comment: If the last idle window is closed instead of quitting idle, it's impossible to launch again idle without logout/login... ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:40 Message: Logged In: YES user_id=75867 Who can tell what the actual problem was? Never anythin like this reported since, get it off the list. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-22 02:16 Message: Logged In: NO explain your setup (os, etc) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486001&group_id=9579 From noreply@sourceforge.net Mon May 20 03:40:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:40:56 -0700 Subject: [Idle-dev] [ idlefork-Bugs-486001 ] Must logout to re-use idle... Message-ID: Bugs item #486001, was opened at 2001-11-28 01:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486001&group_id=9579 Category: None Group: None >Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: Must logout to re-use idle... Initial Comment: If the last idle window is closed instead of quitting idle, it's impossible to launch again idle without logout/login... ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:40 Message: Logged In: YES user_id=75867 Who can tell what the actual problem was? Never anythin like this reported since, get it off the list. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-22 02:16 Message: Logged In: NO explain your setup (os, etc) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486001&group_id=9579 From noreply@sourceforge.net Mon May 20 03:45:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:45:26 -0700 Subject: [Idle-dev] [ idlefork-Bugs-440383 ] beep on no-op enter in shell Message-ID: Bugs item #440383, was opened at 2001-07-11 22:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=440383&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: beep on no-op enter in shell Initial Comment: A bug report. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Mon, 02 Jul 2001 09:07:58 -0500 From: vze2f978@verizon.net To: guido@python.org Subject: IDLE issue--beeping and IDLE hangs If the window looks something like this: >>>(cursor is here) for x in range[w]: and you hit return, IDLE will stop responding, but beep continually until the computer is restarted. This is in Windows 2000. I'm not sure whether the cursor is before or after the invisible space after the ">>>"; the for statement is on the line AFTER the >>>. Don't know why the student used square braces either. ------- End of Forwarded Message ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:45 Message: Logged In: YES user_id=75867 I can reproduce the beep on just enter on linux. Why not consider it a feature, reminding you that pressing enter for nothing in the shell is useless? It seems to happen because of something in undo-delegator, if it actually a serious problem for anyone I'll look into it further... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-30 00:16 Message: Logged In: YES user_id=6380 My apologies. I can't reproduced the described behavior either. What's still broken is that if you press Return at the >>> prompt in the Shell window without entering a command, you get a beep and a new >>> prompt. I could do without the beep (the new >>> prompt is expected. :-) Do you want a separate bug report for that? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-30 00:10 Message: Logged In: YES user_id=6380 It still beeps for me on Linux, with the latest idlefork checkout, using Python 2.1.1. ---------------------------------------------------------------------- Comment By: Chui Tey (teyc) Date: 2001-10-28 20:57 Message: Logged In: YES user_id=29167 I could not reproduce the error on the latest CVS checkout on Win98, using Python 2.1. If any one else still experiences the problem, please let me know, or I'll categorise it as being "not reproducible". ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-07-11 22:26 Message: Logged In: YES user_id=149084 Confirmed on Windows 98 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-07-11 22:25 Message: Logged In: YES user_id=149084 Confirmed on Windows 98 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=440383&group_id=9579 From noreply@sourceforge.net Mon May 20 03:47:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:47:50 -0700 Subject: [Idle-dev] [ idlefork-Bugs-486003 ] idlefork erase source file... Message-ID: Bugs item #486003, was opened at 2001-11-28 01:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486003&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: idlefork erase source file... Initial Comment: Some times, but It's not deterministic, idlefork can't save my file.. In this case, it trie to save it but save only an empty file... To not lose modifications, I need to copy/paste content in another editor and relaunching idlefork... ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:47 Message: Logged In: YES user_id=75867 Fixed in python idle; and fixed in idlefork as part of ongoing process of tracking python idle bug fixes. ---------------------------------------------------------------------- Comment By: Jayce Piel (jayce) Date: 2001-11-28 02:22 Message: Logged In: YES user_id=5496 I identify the source of the problem. It occurs the first time a file is saved after a accentued char is typed in the file (é or è for example). Then, in the console, I have this : Exception in Tkinter callback Traceback (most recent call last): File "/local/edf-python-2.1.1/lib/python2.1/lib-tk/Tkinter.py", line 1285, in __call__ return apply(self.func, args) File "IOBinding.py", line 150, in save if self.writefile(self.filename): File "IOBinding.py", line 176, in writefile f.write(chars) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486003&group_id=9579 From noreply@sourceforge.net Mon May 20 03:49:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:49:55 -0700 Subject: [Idle-dev] [ idlefork-Bugs-502612 ] PyShell strange "else" indentation Message-ID: Bugs item #502612, was opened at 2002-01-12 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=502612&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Peter Maxwell (pm67nz) Assigned to: Nobody/Anonymous (nobody) >Summary: PyShell strange "else" indentation Initial Comment: An else clause entered directly at the PyShell prompt looks like: >>> if 1: print 1 else: print 2 If I try and line up the "else" and "if" I get an IndentationError. OK once you know about it, but confusing for novices. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:49 Message: Logged In: YES user_id=75867 I believe this was debated at length and judged to be correct behaviour in python idle, thus in idlefork also. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=502612&group_id=9579 From noreply@sourceforge.net Mon May 20 03:52:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:52:08 -0700 Subject: [Idle-dev] [ idlefork-Bugs-538584 ] IDLE needs to allow control of eol seq Message-ID: Bugs item #538584, was opened at 2002-04-03 16:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE needs to allow control of eol seq Initial Comment: IDLE tries to respect the end of line sequence of the platform it is running on. However, sometimes this isn't the correct behavior. I want to use IDLE on Windows, but access files on a Samba share. These files are in turn used by Apache, and it's very picky about end-of-line. If the file has CR-LF, it won't execute it. Any time I change a file with IDLE, it resets all the end of line sequences. This also fouls up the ability to diff files, or do CVS merges, because it's a global change. IDLE should either (1) allow an explicit setting for EOL sequence, or (2) figure out what it is for a specific file and then write it out the same way. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:52 Message: Logged In: YES user_id=75867 This item talks about idle rather than idlefork, although I think the behaviour is the same in both cases. Should this be entered as a python idle bug, or perhaps "feature request"? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 From noreply@sourceforge.net Mon May 20 03:58:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 19:58:15 -0700 Subject: [Idle-dev] [ idlefork-Bugs-549159 ] Tabs are messed up Message-ID: Bugs item #549159, was opened at 2002-04-27 02:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Tabs are messed up Initial Comment: Idlefork is not honoring the tab setting in my configuration. It is inserting a tab character, rather than spaces. Also, the column count indicator in the bottom right corner is incorrect because it doesn't appear to be counting tabs. This seems to have broken fairly recently, but I don't know exactly when. The current CVS is definitely broken. I'm on Win98 with Python 2.2.1. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:57 Message: Logged In: YES user_id=75867 Can't reproduce this from current cvs on linux. If you have been running successive cvs versions you should try completely deleting your .idlerc directory and all its contents as the structure of the config files has been changing/stabilising over time. Try that and see if you can reproduce still. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 From noreply@sourceforge.net Mon May 20 04:03:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 20:03:40 -0700 Subject: [Idle-dev] [ idlefork-Bugs-542764 ] Error message in Shell on run Message-ID: Bugs item #542764, was opened at 2002-04-12 10:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=542764&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Williams (mikewilliams) Assigned to: Nobody/Anonymous (nobody) Summary: Error message in Shell on run Initial Comment: Hi, I'm getting the following error message in the Interactive shell (if one is open) when I run a module for which an output window does not already exist. If the output exists then no such error. This doesn't actually seem to do anything (apart from echo the error to Shell) so it's no big problem - just disconcerting for users I guess. I know no Tk(inter) and limited Python so was unable to establish the cause of this: None {: None, : None, : None}Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1292, in __call__ return apply(self.func, args) File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 436, in callit apply(func, args) File "/home/mw/bin/idle/OutputWindow.py", line 86, in set_line_and_column if (self.text.compare(index, ">", "endmark")): File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 2651, in compare return self.tk.getboolean(self.tk.call( TclError: expected boolean value but got "" This is on Python 2.2.1c1 in Debian Linux with an idlefork CVS grabbed 2002-04-11 with Tk and Tkinter 8.3. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 13:03 Message: Logged In: YES user_id=75867 I can reproduce this with 2.2.1 final and latest cvs also under linux. Confirm it to be non-fatal. Will look into it when I get a chance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=542764&group_id=9579 From noreply@sourceforge.net Mon May 20 04:05:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 20:05:01 -0700 Subject: [Idle-dev] [ idlefork-Bugs-441472 ] Non-latin1 encodings under Windows. Message-ID: Bugs item #441472, was opened at 2001-07-16 03:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441472&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Non-latin1 encodings under Windows. Initial Comment: The attached problem description was submitted to the python list by Roman Suzi. The problem involves internationalization issues and non-latin1 characters under Windows. The problem is described in great detail and solutions are provided. This should probably be a high priority item for the IDLE revitalization effort. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 13:05 Message: Logged In: YES user_id=75867 Should/has this be(een) adressed in python idle? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441472&group_id=9579 From noreply@sourceforge.net Mon May 20 04:07:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 20:07:39 -0700 Subject: [Idle-dev] [ idlefork-Patches-450716 ] Most Recently used files Message-ID: Patches item #450716, was opened at 2001-08-14 16:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=450716&group_id=9579 Category: None Group: None >Status: Closed Resolution: Postponed Priority: 5 Submitted By: Chui Tey (teyc) Assigned to: Stephen M. Gava (elguavas) Summary: Most Recently used files Initial Comment: *** old/EditorWindow.py Sun Aug 12 22:06:16 2001 --- new/EditorWindow.py Tue Aug 14 09:51:14 2001 *************** *** 15,20 **** --- 15,21 ---- import webbrowser import idlever + import MRUList import WindowList from IdleConf import idleconf *************** *** 138,143 **** --- 139,147 ---- self.createmenubar() self.apply_bindings() + self.mrulist=MRUList.MRUList() + self.mrumenu=MRUList.MRUMenu(self.menudict ['file'], self.mrulist) + self.top.protocol("WM_DELETE_WINDOW", self.close) self.top.bind("<>", self.close_event) text.bind("<>", self.center_insert_event) *************** *** 425,430 **** --- 432,441 ---- self.addcolorizer() else: self.rmcolorizer() + # update the MRU list, and the menu + if self.io.filename: + self.mrulist.add(self.io.filename) + self.mrumenu.update() def addcolorizer(self): if self.color: #-------------------------------------------------- # MRUList.py # Most Recently Used list of files # # class MRUList - maintains a list of most recently used files # class MRUMenu - creates a menu of most recently used files # import ConfigParser from Tkinter import * # Default section name SECTION = 'MRUList' class MRUList: """Maintains a most recently used file list. The list is stored in $HOME/.idle See also: MRUMenu (for presentational logic) """ def __init__(self): self.max = 4 self._list = [] self._read() # PUBLIC Methods -------------------------------- def add(self, filename): """Adds a new filename to the most recently used list """ # maintain the MRU as a stack # with the most recent at the top of the stack # self._read() # get the latest from the config file if filename in self._list: self.delete(filename) self._list.append(filename) self._trim() self._write() # write it back immediately, more crash-proof def delete(self, filename): """Removes a filename from the most recently used list. Should be called when the file no longer exists. """ try: self._list.remove(filename) except ValueError: # Just in case item doesn't exist pass def list(self): """List of most recently used files, newest at the end""" return self._list # PRIVATE Methods ------------------------------- def __del__(self): # # Upon destruction, update the mrulist # self._trim() self._write() def __repr__(self): return ("max: %d\ncount: %d\n" % (self.max, len (self._list)) \ + `self._list`) def _getfilename(self): """Returns the file name of the config file""" # Copied from IdleConf.py import os try: homedir = os.environ['HOME'] except KeyError: homedir = os.getcwd() return os.path.join(homedir, '.idle') def _trim(self): """Trims the MRU list to the maximum specified""" too_many = len(self._list) - self.max if too_many > 0: self._list = self._list[too_many:] def _read(self): """Reads the config.txt for the list of MRU files""" self.conf = conf = ConfigParser.ConfigParser() conf.read(self._getfilename()) if not conf.has_section(SECTION): conf.add_section(SECTION) try: self.max = max = conf.getint (SECTION, 'max') count = conf.getint(SECTION, 'count') for i in range(count): filename=conf.get(SECTION, "file%d" % (i+1)) if not filename in self._list: self._list.append(filename) except ConfigParser.NoOptionError: pass def _write(self): """Writes the list of MRU files to .idle""" conf = self.conf conf.set(SECTION, 'enable', 0) # This is not an idle extension conf.set(SECTION, 'max', self.max) conf.set(SECTION, 'count', len(self._list)) for i in range(len(self._list)): conf.set(SECTION, "file%d" % (i+1), self._list[i]) conf.write(open(self._getfilename(),'wb')) class MRUMenu(Menu): """Maintains a menu associated with an MRU List. When an item on the MRUList is selected, a callback function calls open() on the EditorWindow which owns the menu. See also: MRUList """ def __init__(self, parent, mrulist): self.parent = parent # parent window self.mrulist = mrulist # instance of MRUList self.prev_mrumenus = {} # previous mru list self.parent.add_separator() self.update() def update(self): """Updates the MRU menu""" # # Build a reversed list of MRU files # import copy list = copy.copy(self.mrulist.list()) list.reverse() # # convert list to list of menu labels # menulist = [] for counter, filename in zip(range(len(list)), list): label = "%d %s" % (counter+1, filename) menulist.append( (label, filename) ) # # replace invalid mru with valid ones # for index in range(len(menulist)): menulabel, filename = menulist[index] if self.prev_mrumenus.has_key( index ): menu_index = self.parent.index( self.prev_mrumenus[index] ) self.parent.entryconfig( menu_index, \ label=menulabel, \ command=self._callback(filename)) self.prev_mrumenus[index] = filename else: self.parent.add_command( \ label=menulabel, \ underline=0, \ command = self._callback (filename)) self.prev_mrumenus[index] = filename def _callback(self, filename): """Returns a callback function which opens a file with a given filename""" def open(filename=filename): # # XXX todo. open('test','a').write("Opening %s (MRUList.py)...\n" % filename) return open def test(): mrulist = MRUList() mrulist.add('testMRU-1.py') mrulist.add('testMRU-2.py') mrulist.add('testMRU-3.py') mrulist.add('testMRU-4.py') mrulist.add('testMRU-5.py') mrulist.add('testMRU-6.py') print mrulist if __name__ == '__main__': test() ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 13:07 Message: Logged In: YES user_id=75867 An mru files implementation is already in cvs idlefork now. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-08 12:46 Message: Logged In: YES user_id=75867 an mru implementation is on our todo list, but it will have to wait until after the new configuration handling is in place ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=450716&group_id=9579 From noreply@sourceforge.net Mon May 20 04:09:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 20:09:47 -0700 Subject: [Idle-dev] [ idlefork-Patches-540616 ] MS HTML Help Python Docs Message-ID: Patches item #540616, was opened at 2002-04-08 02:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=540616&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: MS HTML Help Python Docs Initial Comment: There was some discussion at Python Dev about adding Python Docs in MS HTML Help format. If that happens IDLE should point to the new docs. This patch enable this. A similar one for Python bundled IDLE is at: http://www.python.org/sf/540583 You can found more info for this type of Docs at http://www.orgmf.com.ar/condor/pytsfuff.html ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 13:09 Message: Logged In: YES user_id=75867 This was applied to idlefork immediately it was applied to python idle, as part of normal tracking of stable python changes. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-19 02:19 Message: Logged In: YES user_id=112690 FYI, the IDLE patch 540583 were applied to Python's current CVS. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-08 05:25 Message: Logged In: YES user_id=112690 a new patch. if the .chm file doesn't exist try with the bundled docs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=540616&group_id=9579 From noreply@sourceforge.net Mon May 20 04:11:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 20:11:32 -0700 Subject: [Idle-dev] [ idlefork-Patches-508973 ] Support national characters Message-ID: Patches item #508973, was opened at 2002-01-27 08:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Support national characters Initial Comment: With the attached patch, IDLE will allow to edit text with national characters, and properly save the file. To achieve this, several mechanisms are used: 1. If the file has an emacs-style coding declartion (e.g. -*- coding: koi8-r -*-), this encoding will be used to load and store the file. 2. Otherwise, the locale's encoding will be used. This is determined as "mbcs" on Windows, and nl_langinfo(CODESET) on Unix (requires Python 2.2). If determination fails, "ascii" is used. 3. The text is encoded/decoded to the encoding determined above. If that fails, saving falls back to UTF-8, and loading falls back to passing a byte string to Tcl. 4. In PyShell interactive mode, IOBinding.encoding is used to encode Unicode strings before compiling them. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 13:11 Message: Logged In: YES user_id=75867 Are you intending this patch for python idle? If so you need to submit it to the python patch manager. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 08:37 Message: Logged In: YES user_id=21627 If you want to verify that the patch functions correctly, please open the attached mvl.py, which should have two strings; a latin one (with a single umlaut) and a cyrillic one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 From noreply@sourceforge.net Mon May 20 11:51:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 03:51:50 -0700 Subject: [Idle-dev] [ idlefork-Bugs-440383 ] beep on no-op enter in shell Message-ID: Bugs item #440383, was opened at 2001-07-11 08:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=440383&group_id=9579 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: beep on no-op enter in shell Initial Comment: A bug report. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Mon, 02 Jul 2001 09:07:58 -0500 From: vze2f978@verizon.net To: guido@python.org Subject: IDLE issue--beeping and IDLE hangs If the window looks something like this: >>>(cursor is here) for x in range[w]: and you hit return, IDLE will stop responding, but beep continually until the computer is restarted. This is in Windows 2000. I'm not sure whether the cursor is before or after the invisible space after the ">>>"; the for statement is on the line AFTER the >>>. Don't know why the student used square braces either. ------- End of Forwarded Message ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 06:51 Message: Logged In: YES user_id=6380 I know it's very minor, but I believe it might point to some unsound code somewhere deep in the bowels of undo. Definitely low priority. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 22:45 Message: Logged In: YES user_id=75867 I can reproduce the beep on just enter on linux. Why not consider it a feature, reminding you that pressing enter for nothing in the shell is useless? It seems to happen because of something in undo-delegator, if it actually a serious problem for anyone I'll look into it further... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-29 08:16 Message: Logged In: YES user_id=6380 My apologies. I can't reproduced the described behavior either. What's still broken is that if you press Return at the >>> prompt in the Shell window without entering a command, you get a beep and a new >>> prompt. I could do without the beep (the new >>> prompt is expected. :-) Do you want a separate bug report for that? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-29 08:10 Message: Logged In: YES user_id=6380 It still beeps for me on Linux, with the latest idlefork checkout, using Python 2.1.1. ---------------------------------------------------------------------- Comment By: Chui Tey (teyc) Date: 2001-10-28 04:57 Message: Logged In: YES user_id=29167 I could not reproduce the error on the latest CVS checkout on Win98, using Python 2.1. If any one else still experiences the problem, please let me know, or I'll categorise it as being "not reproducible". ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-07-11 08:26 Message: Logged In: YES user_id=149084 Confirmed on Windows 98 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-07-11 08:25 Message: Logged In: YES user_id=149084 Confirmed on Windows 98 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=440383&group_id=9579 From noreply@sourceforge.net Mon May 20 11:53:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 03:53:39 -0700 Subject: [Idle-dev] [ idlefork-Bugs-441475 ] Wrong initial numbers in status bar. Message-ID: Bugs item #441475, was opened at 2001-07-15 13:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441475&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong initial numbers in status bar. Initial Comment: When IDLE is run (on Win98, at least) it displays incorrect line and column numbers in the status bar - lin: 1 col: 3 should be lin: 7 col: 4. As soon as the cursor is moved the status bar is updated with the proper information. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 06:53 Message: Logged In: YES user_id=6380 I can still reproduce something like this on Linux. Bring up the Python Shell window from the Run menu. Notice that it displays 0 for the column number (the line number is correct). ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 22:37 Message: Logged In: YES user_id=75867 Can anyone with win98 still reproduce this problem? I think it may have been fixed ages ago. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441475&group_id=9579 From noreply@sourceforge.net Mon May 20 11:54:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 03:54:47 -0700 Subject: [Idle-dev] [ idlefork-Bugs-486001 ] Must logout to re-use idle... Message-ID: Bugs item #486001, was opened at 2001-11-27 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486001&group_id=9579 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: Must logout to re-use idle... Initial Comment: If the last idle window is closed instead of quitting idle, it's impossible to launch again idle without logout/login... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 06:54 Message: Logged In: YES user_id=6380 I imagine his window manager wasn't notifying the application. Not worth the bother. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 22:40 Message: Logged In: YES user_id=75867 Who can tell what the actual problem was? Never anythin like this reported since, get it off the list. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-21 10:16 Message: Logged In: NO explain your setup (os, etc) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=486001&group_id=9579 From noreply@sourceforge.net Mon May 20 12:00:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 04:00:22 -0700 Subject: [Idle-dev] [ idlefork-Bugs-538584 ] IDLE needs to allow control of eol seq Message-ID: Bugs item #538584, was opened at 2002-04-03 01:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE needs to allow control of eol seq Initial Comment: IDLE tries to respect the end of line sequence of the platform it is running on. However, sometimes this isn't the correct behavior. I want to use IDLE on Windows, but access files on a Samba share. These files are in turn used by Apache, and it's very picky about end-of-line. If the file has CR-LF, it won't execute it. Any time I change a file with IDLE, it resets all the end of line sequences. This also fouls up the ability to diff files, or do CVS merges, because it's a global change. IDLE should either (1) allow an explicit setting for EOL sequence, or (2) figure out what it is for a specific file and then write it out the same way. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 07:00 Message: Logged In: YES user_id=6380 Definitely a feature request. I'm sure both IDLE versions have this issue. It will be possible to fix this in Python 2.3 by using the Universal Newlines feature (see PEP 278) -- that will let IDLE determine the original newline convention. Writing back using that convention is then (relatively) simple, using binary output mode. (But you'll have to get the text from the Text widget a line at a time, or do a global replace of \n with the line ending of choice.) ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 22:52 Message: Logged In: YES user_id=75867 This item talks about idle rather than idlefork, although I think the behaviour is the same in both cases. Should this be entered as a python idle bug, or perhaps "feature request"? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 From noreply@sourceforge.net Mon May 20 13:28:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 05:28:49 -0700 Subject: [Idle-dev] [ idlefork-Bugs-549159 ] Tabs are messed up Message-ID: Bugs item #549159, was opened at 2002-04-26 11:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Tabs are messed up Initial Comment: Idlefork is not honoring the tab setting in my configuration. It is inserting a tab character, rather than spaces. Also, the column count indicator in the bottom right corner is incorrect because it doesn't appear to be counting tabs. This seems to have broken fairly recently, but I don't know exactly when. The current CVS is definitely broken. I'm on Win98 with Python 2.2.1. ---------------------------------------------------------------------- >Comment By: Patrick K. O'Brien (pobrien) Date: 2002-05-20 07:28 Message: Logged In: YES user_id=179604 I can still reproduce this problem. I'm using the latest from CVS. I deleted my .idlerc directory. I can open aboutDialog.py, hit tab and get a tab character with a spacing of 8 column positions, instead of the tab key inserting 4 spaces as specified by the default configuration. Here are the contents of my config-main.cfg file: [EditorWindow] height = 40 font = Courier New font-size = 10 ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 21:57 Message: Logged In: YES user_id=75867 Can't reproduce this from current cvs on linux. If you have been running successive cvs versions you should try completely deleting your .idlerc directory and all its contents as the structure of the config files has been changing/stabilising over time. Try that and see if you can reproduce still. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 From noreply@sourceforge.net Tue May 21 01:18:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 17:18:00 -0700 Subject: [Idle-dev] [ idlefork-Bugs-441472 ] Non-latin1 encodings under Windows. Message-ID: Bugs item #441472, was opened at 2001-07-15 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441472&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Non-latin1 encodings under Windows. Initial Comment: The attached problem description was submitted to the python list by Roman Suzi. The problem involves internationalization issues and non-latin1 characters under Windows. The problem is described in great detail and solutions are provided. This should probably be a high priority item for the IDLE revitalization effort. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 20:18 Message: Logged In: YES user_id=6380 How old is that email? The FixTk.py problem has been fixed in Python 2.2. I hope that someone will fix the Unicode handling in _tkinter.c and submit a patch to the Python patch manager. Otherwise this will never get fixed. (The regular maintainer of _tkinter.c has no access to systems where foreign encodings are used for testing.) I don't understand why the default encoding must be changed. If the user enters non-ASCII characters Tcl will automatically produce Unicode. If the issue is that there are source code files encoded in national encoding, please wait for PEP 263 -- IDLE should be patched to support the same convention. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 23:05 Message: Logged In: YES user_id=75867 Should/has this be(een) adressed in python idle? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=441472&group_id=9579 From noreply@sourceforge.net Tue May 21 01:26:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 17:26:06 -0700 Subject: [Idle-dev] [ idlefork-Patches-508973 ] Support national characters Message-ID: Patches item #508973, was opened at 2002-01-26 16:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Support national characters Initial Comment: With the attached patch, IDLE will allow to edit text with national characters, and properly save the file. To achieve this, several mechanisms are used: 1. If the file has an emacs-style coding declartion (e.g. -*- coding: koi8-r -*-), this encoding will be used to load and store the file. 2. Otherwise, the locale's encoding will be used. This is determined as "mbcs" on Windows, and nl_langinfo(CODESET) on Unix (requires Python 2.2). If determination fails, "ascii" is used. 3. The text is encoded/decoded to the encoding determined above. If that fails, saving falls back to UTF-8, and loading falls back to passing a byte string to Tcl. 4. In PyShell interactive mode, IOBinding.encoding is used to encode Unicode strings before compiling them. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 20:26 Message: Logged In: YES user_id=6380 I think MvL knows what to do with patches for Python IDLE. :-) I recommend applying this patch unless it doesn't work. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 23:11 Message: Logged In: YES user_id=75867 Are you intending this patch for python idle? If so you need to submit it to the python patch manager. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-26 16:37 Message: Logged In: YES user_id=21627 If you want to verify that the patch functions correctly, please open the attached mvl.py, which should have two strings; a latin one (with a single umlaut) and a cyrillic one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 From noreply@sourceforge.net Tue May 21 02:02:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 18:02:58 -0700 Subject: [Idle-dev] [ idlefork-Patches-508973 ] Support national characters Message-ID: Patches item #508973, was opened at 2002-01-27 08:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Support national characters Initial Comment: With the attached patch, IDLE will allow to edit text with national characters, and properly save the file. To achieve this, several mechanisms are used: 1. If the file has an emacs-style coding declartion (e.g. -*- coding: koi8-r -*-), this encoding will be used to load and store the file. 2. Otherwise, the locale's encoding will be used. This is determined as "mbcs" on Windows, and nl_langinfo(CODESET) on Unix (requires Python 2.2). If determination fails, "ascii" is used. 3. The text is encoded/decoded to the encoding determined above. If that fails, saving falls back to UTF-8, and loading falls back to passing a byte string to Tcl. 4. In PyShell interactive mode, IOBinding.encoding is used to encode Unicode strings before compiling them. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-21 11:02 Message: Logged In: YES user_id=75867 Sure. Let me put it another way: The original message mentions IDLE itself and I agree with that hint that this seems to be an important issue that should perhaps be adressed in python idle itself and tracked in idlefork. So, is the reason for submitting this to idlefork rather that idle that these changes may have unforseen results, and therefore would be better to be tested in idlefork first? Martin? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 10:26 Message: Logged In: YES user_id=6380 I think MvL knows what to do with patches for Python IDLE. :-) I recommend applying this patch unless it doesn't work. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 13:11 Message: Logged In: YES user_id=75867 Are you intending this patch for python idle? If so you need to submit it to the python patch manager. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 08:37 Message: Logged In: YES user_id=21627 If you want to verify that the patch functions correctly, please open the attached mvl.py, which should have two strings; a latin one (with a single umlaut) and a cyrillic one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 From noreply@sourceforge.net Tue May 21 02:11:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 18:11:12 -0700 Subject: [Idle-dev] [ idlefork-Bugs-549159 ] Tabs are messed up Message-ID: Bugs item #549159, was opened at 2002-04-27 02:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Tabs are messed up Initial Comment: Idlefork is not honoring the tab setting in my configuration. It is inserting a tab character, rather than spaces. Also, the column count indicator in the bottom right corner is incorrect because it doesn't appear to be counting tabs. This seems to have broken fairly recently, but I don't know exactly when. The current CVS is definitely broken. I'm on Win98 with Python 2.2.1. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-21 11:11 Message: Logged In: YES user_id=75867 Ok. I just booted one of the boxes here in to windows 2000 (a couple of machines on our little lan optionally run it, but unfortunately I have no windows 98 that I can test against) and the described problem did not occur; I openned aboutDialog.py and tabbing worked as expected, defaulting to four spaces. That was under python 2.2 (with its built in tk 8.3). So then I upgraded that machine to python 2.2.1 (again with its built in tk 8.3) and again I could not reproduce the problem described. So it may be something win98 specific (seems odd, but I guess possible). Can someone else with windows 98 available try this out?? Or else it may be something else specific to your setup, for instance, do you have some other version of tcl/tk also installed? ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-05-20 22:28 Message: Logged In: YES user_id=179604 I can still reproduce this problem. I'm using the latest from CVS. I deleted my .idlerc directory. I can open aboutDialog.py, hit tab and get a tab character with a spacing of 8 column positions, instead of the tab key inserting 4 spaces as specified by the default configuration. Here are the contents of my config-main.cfg file: [EditorWindow] height = 40 font = Courier New font-size = 10 ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:57 Message: Logged In: YES user_id=75867 Can't reproduce this from current cvs on linux. If you have been running successive cvs versions you should try completely deleting your .idlerc directory and all its contents as the structure of the config files has been changing/stabilising over time. Try that and see if you can reproduce still. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 From elguavas@users.sourceforge.net Tue May 21 07:14:05 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 21 May 2002 16:14:05 +1000 Subject: [Idle-dev] idlefork - developer list Message-ID: <1021961645.3543.9.camel@oberon> Hi all, since I just received another email asking me why a project with seven developers is moving so slowly, I decided to remove those who have been inactive for a long period of time from the project developer list at sourceforge; who knows, it might even inspire some new volunteers for the project. If you were one of those who asked to be left on the developer list "just in case", and you feel that you would still like to make contributions that can't be made through the patch or bug trackers, please, by all means, let me know and I'll happily reinstate you. Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From elguavas@users.sourceforge.net Tue May 21 07:22:27 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 21 May 2002 16:22:27 +1000 Subject: [Idle-dev] idlefork - win98 tab bug? Message-ID: <1021962147.3543.18.camel@oberon> Howdy. Sourceforge idlefork bug tracker bug #549159 reports a problem with the operation of tabs under win98 for latest cvs idlefork. I can't reproduce this bug under linux or windows 2000, but I don't have win98 available, so if anyone who does is playing with cvs idlefork could they try and see if they encounter this problem for me? Cheers, Stephen. I've pasted some of the bug history below FYI. =========== begin paste =============== Bugs item #549159, was opened at 2002-04-27 02:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Tabs are messed up Initial Comment: Idlefork is not honoring the tab setting in my configuration. It is inserting a tab character, rather than spaces. Also, the column count indicator in the bottom right corner is incorrect because it doesn't appear to be counting tabs. This seems to have broken fairly recently, but I don't know exactly when. The current CVS is definitely broken. I'm on Win98 with Python 2.2.1. ---------------------------------------------------------------------- >Comment By: Stephen M. Gava (elguavas) Date: 2002-05-21 11:11 Message: Logged In: YES user_id=75867 Ok. I just booted one of the boxes here in to windows 2000 (a couple of machines on our little lan optionally run it, but unfortunately I have no windows 98 that I can test against) and the described problem did not occur; I openned aboutDialog.py and tabbing worked as expected, defaulting to four spaces. That was under python 2.2 (with its built in tk 8.3). So then I upgraded that machine to python 2.2.1 (again with its built in tk 8.3) and again I could not reproduce the problem described. So it may be something win98 specific (seems odd, but I guess possible). Can someone else with windows 98 available try this out?? Or else it may be something else specific to your setup, for instance, do you have some other version of tcl/tk also installed? ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-05-20 22:28 Message: Logged In: YES user_id=179604 I can still reproduce this problem. I'm using the latest from CVS. I deleted my .idlerc directory. I can open aboutDialog.py, hit tab and get a tab character with a spacing of 8 column positions, instead of the tab key inserting 4 spaces as specified by the default configuration. Here are the contents of my config-main.cfg file: [EditorWindow] height = 40 font = Courier New font-size = 10 ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 12:57 Message: Logged In: YES user_id=75867 Can't reproduce this from current cvs on linux. If you have been running successive cvs versions you should try completely deleting your .idlerc directory and all its contents as the structure of the config files has been changing/stabilising over time. Try that and see if you can reproduce still. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=549159&group_id=9579 =========== end paste ========== -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From noreply@sourceforge.net Tue May 21 10:02:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 02:02:23 -0700 Subject: [Idle-dev] [ idlefork-Patches-508973 ] Support national characters Message-ID: Patches item #508973, was opened at 2002-01-26 22:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 Category: None Group: None >Status: Pending >Resolution: Remind Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Support national characters Initial Comment: With the attached patch, IDLE will allow to edit text with national characters, and properly save the file. To achieve this, several mechanisms are used: 1. If the file has an emacs-style coding declartion (e.g. -*- coding: koi8-r -*-), this encoding will be used to load and store the file. 2. Otherwise, the locale's encoding will be used. This is determined as "mbcs" on Windows, and nl_langinfo(CODESET) on Unix (requires Python 2.2). If determination fails, "ascii" is used. 3. The text is encoded/decoded to the encoding determined above. If that fails, saving falls back to UTF-8, and loading falls back to passing a byte string to Tcl. 4. In PyShell interactive mode, IOBinding.encoding is used to encode Unicode strings before compiling them. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-21 11:02 Message: Logged In: YES user_id=21627 I would actually like to withdraw this patch for the moment. It is part of the PEP 263, but does not implement it correctly (i.e. no BOM processing, no error messages). ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-21 03:02 Message: Logged In: YES user_id=75867 Sure. Let me put it another way: The original message mentions IDLE itself and I agree with that hint that this seems to be an important issue that should perhaps be adressed in python idle itself and tracked in idlefork. So, is the reason for submitting this to idlefork rather that idle that these changes may have unforseen results, and therefore would be better to be tested in idlefork first? Martin? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 02:26 Message: Logged In: YES user_id=6380 I think MvL knows what to do with patches for Python IDLE. :-) I recommend applying this patch unless it doesn't work. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-20 05:11 Message: Logged In: YES user_id=75867 Are you intending this patch for python idle? If so you need to submit it to the python patch manager. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-26 22:37 Message: Logged In: YES user_id=21627 If you want to verify that the patch functions correctly, please open the attached mvl.py, which should have two strings; a latin one (with a single umlaut) and a cyrillic one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=309579&aid=508973&group_id=9579 From noreply@sourceforge.net Tue May 21 15:10:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 07:10:15 -0700 Subject: [Idle-dev] [ idlefork-Bugs-558687 ] Printing arrays misses elements Message-ID: Bugs item #558687, was opened at 2002-05-21 14:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Williams (mikewilliams) Assigned to: Nobody/Anonymous (nobody) Summary: Printing arrays misses elements Initial Comment: IDLEfork seems to be missing out an inconsistent number of the final few elements of a Numeric array when asked to print them. This has been replicated on both Linux and Solaris with Python2.2.1 and IDLEfork 0.8.1 Consider the following code snippet (problem exhibited both if run from module or typed at shell): from Numeric import * #Import Numeric (an array #library) xx = zeros(100, Float) #Create an empty array of #100 floats for i in range(100): xx[i] = i #Put numbers 0 to 99 in the #array print xx #Print the array (see the #problem?) print xx[99] #Although xx[99] does exist! This problem doesn't seem to occur much below 100 element arrays (although see, e.g. 87), but seems to get more severe above it. See, for example 102-108 (not 109 or 110), 150, 200, 1000 (which prints the first 947 elements!). I could not find a corellation between window width and the number of elements that were printed (which appears to be constant). Ther seems to be some reluctance to start a new line when printing until there are sufficient elements to put on it. This is a medium severity problem, especially for interactive work. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 From noreply@sourceforge.net Tue May 21 15:36:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 07:36:05 -0700 Subject: [Idle-dev] [ idlefork-Bugs-558687 ] Printing arrays misses elements Message-ID: Bugs item #558687, was opened at 2002-05-21 14:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Williams (mikewilliams) Assigned to: Nobody/Anonymous (nobody) Summary: Printing arrays misses elements Initial Comment: IDLEfork seems to be missing out an inconsistent number of the final few elements of a Numeric array when asked to print them. This has been replicated on both Linux and Solaris with Python2.2.1 and IDLEfork 0.8.1 Consider the following code snippet (problem exhibited both if run from module or typed at shell): from Numeric import * #Import Numeric (an array #library) xx = zeros(100, Float) #Create an empty array of #100 floats for i in range(100): xx[i] = i #Put numbers 0 to 99 in the #array print xx #Print the array (see the #problem?) print xx[99] #Although xx[99] does exist! This problem doesn't seem to occur much below 100 element arrays (although see, e.g. 87), but seems to get more severe above it. See, for example 102-108 (not 109 or 110), 150, 200, 1000 (which prints the first 947 elements!). I could not find a corellation between window width and the number of elements that were printed (which appears to be constant). Ther seems to be some reluctance to start a new line when printing until there are sufficient elements to put on it. This is a medium severity problem, especially for interactive work. ---------------------------------------------------------------------- >Comment By: Michael Williams (mikewilliams) Date: 2002-05-21 14:36 Message: Logged In: YES user_id=258804 This does not occur in the IDLE distributed with the Python source. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 From elguavas@users.sourceforge.net Wed May 22 01:36:50 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 21 May 2002 17:36:50 -0700 Subject: [Idle-dev] CVS: website tasklist.txt,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/website In directory usw-pr-cvs1:/tmp/cvs-serv6404 Modified Files: tasklist.txt Log Message: update Index: tasklist.txt =================================================================== RCS file: /cvsroot/idlefork/website/tasklist.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** tasklist.txt 29 Oct 2001 00:23:50 -0000 1.2 --- tasklist.txt 22 May 2002 00:36:48 -0000 1.3 *************** *** 21,37 **** for programs being developed in IDLE ! Compare / evaluate David Scherer (currently Chui Tey in IDLEfork) v. GvR code for this and implement best solution. ! Solve rpc security problems. Chui Tey Make sure things work properly with shell ! window and debugging. Chui Tey ------------------------------------------------------------------ Stabilisation ! Finish initial merge cleanup / fixup to Everyone ! stable state. Get debugging working! Bug fixing. Everyone --- 21,36 ---- for programs being developed in IDLE ! Compare / evaluate David Scherer (currently ? in IDLEfork) v. GvR code for this and implement best solution. ! Solve rpc security problems. ? Make sure things work properly with shell ! window and debugging. ? ------------------------------------------------------------------ Stabilisation ! Get debugging working properly! ? Bug fixing. Everyone *************** *** 58,61 **** --- 57,62 ---- Colour configuration. Stephen M. Gava + Full GUI Configurability. Stephen M. Gava + General look and feel issues Stephen M. Gava (appearance / consistency / From elguavas@users.sourceforge.net Wed May 22 01:38:23 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 21 May 2002 17:38:23 -0700 Subject: [Idle-dev] CVS: website index.html,1.1,1.2 Message-ID: Update of /cvsroot/idlefork/website In directory usw-pr-cvs1:/tmp/cvs-serv6771 Modified Files: index.html Log Message: fix typo Index: index.html =================================================================== RCS file: /cvsroot/idlefork/website/index.html,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** index.html 24 Jul 2001 12:33:20 -0000 1.1 --- index.html 22 May 2002 00:38:21 -0000 1.2 *************** *** 131,135 **** for life (python's creator, Guido van Rossum) will go back into the stable distribution version.

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

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


How To Contribute

Everyone interested in IDLE is invited to contribute to the IDLEfork by --- 131,135 ---- for life (python's creator, Guido van Rossum) will go back into the stable distribution version.

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

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


How To Contribute

Everyone interested in IDLE is invited to contribute to the IDLEfork by From lolita86@libero.it Thu May 23 17:19:02 2002 From: lolita86@libero.it (lolita) Date: Thu, 23 May 2002 23.18.46 +0200 Subject: [Idle-dev] Eros e soldi:guadagna con internet 0,08 euro a clic Message-ID: sono lolita=2C voglio presentarti il mio nuovo sito affiliazione gratuita con guadagni immediati=3A erotismo=2C chat=2Cloghi e sonerie etc=2C etc=2C l'unico sito che paga cos=EC tanto 0=2C08 euro a clic =2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Eguarda bene la pg di affiliazione=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Ee buon divertimento=2E visita il sito=3A http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 From teyc@users.sourceforge.net Sun May 26 14:36:44 2002 From: teyc@users.sourceforge.net (Chui Tey) Date: Sun, 26 May 2002 06:36:44 -0700 Subject: [Idle-dev] CVS: idle RemoteObjectBrowser.py,NONE,1.1 RemoteDebugger.py,NONE,1.1 rpc.py,NONE,1.1 run.py,NONE,1.1 ScriptBinding.py,1.4,1.5 Debugger.py,1.4,1.5 PyShell.py,1.13,1.14 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv5459 Modified Files: ScriptBinding.py Debugger.py PyShell.py Added Files: RemoteObjectBrowser.py RemoteDebugger.py rpc.py run.py Log Message: GvR's rpc patch --- NEW FILE: RemoteObjectBrowser.py --- import rpc def remote_object_tree_item(item): wrapper = WrappedObjectTreeItem(item) oid = id(wrapper) rpc.objecttable[oid] = wrapper return oid class WrappedObjectTreeItem: # Lives in PYTHON subprocess def __init__(self, item): self.__item = item def __getattr__(self, name): value = getattr(self.__item, name) return value def _GetSubList(self): list = self.__item._GetSubList() return map(remote_object_tree_item, list) class StubObjectTreeItem: # Lives in IDLE process def __init__(self, sockio, oid): self.sockio = sockio self.oid = oid def __getattr__(self, name): value = rpc.MethodProxy(self.sockio, self.oid, name) return value def _GetSubList(self): list = self.sockio.remotecall(self.oid, "_GetSubList", (), {}) return [StubObjectTreeItem(self.sockio, oid) for oid in list] --- NEW FILE: RemoteDebugger.py --- """Support for remote Python debugging. Some ASCII art to describe the structure: IN PYTHON SUBPROCESS # IN IDLE PROCESS # # oid='gui_adapter' +----------+ # +------------+ +-----+ | GUIProxy |--remote#call-->| GUIAdapter |--calls-->| GUI | +-----+--calls-->+----------+ # +------------+ +-----+ | Idb | # / +-----+<-calls--+------------+ # +----------+<--calls-/ | IdbAdapter |<--remote#call--| IdbProxy | +------------+ # +----------+ oid='idb_adapter' # The purpose of the Proxy and Adapter classes is to translate certain arguments and return values that cannot be transported through the RPC barrier, in particular frame and traceback objects. """ import sys import rpc import Debugger # In the PYTHON subprocess frametable = {} dicttable = {} codetable = {} def wrap_frame(frame): fid = id(frame) frametable[fid] = frame return fid def wrap_info(info): if info is None: return None else: return None # XXX for now class GUIProxy: def __init__(self, conn, oid): self.conn = conn self.oid = oid def interaction(self, message, frame, info=None): self.conn.remotecall(self.oid, "interaction", (message, wrap_frame(frame), wrap_info(info)), {}) class IdbAdapter: def __init__(self, idb): self.idb = idb def set_step(self): self.idb.set_step() def set_quit(self): self.idb.set_quit() def set_continue(self): self.idb.set_continue() def set_next(self, fid): frame = frametable[fid] self.idb.set_next(frame) def set_return(self, fid): frame = frametable[fid] self.idb.set_return(frame) def get_stack(self, fid, tbid): ##print >>sys.__stderr__, "get_stack(%s, %s)" % (`fid`, `tbid`) frame = frametable[fid] tb = None # XXX for now stack, i = self.idb.get_stack(frame, tb) ##print >>sys.__stderr__, "get_stack() ->", stack stack = [(wrap_frame(frame), k) for frame, k in stack] ##print >>sys.__stderr__, "get_stack() ->", stack return stack, i def run(self, cmd): import __main__ self.idb.run(cmd, __main__.__dict__) def frame_attr(self, fid, name): frame = frametable[fid] return getattr(frame, name) def frame_globals(self, fid): frame = frametable[fid] dict = frame.f_globals did = id(dict) dicttable[did] = dict return did def frame_locals(self, fid): frame = frametable[fid] dict = frame.f_locals did = id(dict) dicttable[did] = dict return did def frame_code(self, fid): frame = frametable[fid] code = frame.f_code cid = id(code) codetable[cid] = code return cid def code_name(self, cid): code = codetable[cid] return code.co_name def code_filename(self, cid): code = codetable[cid] return code.co_filename def dict_keys(self, did): dict = dicttable[did] return dict.keys() def dict_item(self, did, key): dict = dicttable[did] value = dict[key] try: # Test for picklability import cPickle cPickle.dumps(value) except: value = None return value def start_debugger(conn, gui_oid): # # launched in the python subprocess # gui = GUIProxy(conn, gui_oid) idb = Debugger.Idb(gui) ada = IdbAdapter(idb) ada_oid = "idb_adapter" conn.register(ada_oid, ada) return ada_oid # In the IDLE process class FrameProxy: def __init__(self, conn, fid): self._conn = conn self._fid = fid self._oid = "idb_adapter" self._dictcache = {} def __getattr__(self, name): if name[:1] == "_": raise AttributeError, name if name == "f_code": return self._get_f_code() if name == "f_globals": return self._get_f_globals() if name == "f_locals": return self._get_f_locals() return self._conn.remotecall(self._oid, "frame_attr", (self._fid, name), {}) def _get_f_code(self): cid = self._conn.remotecall(self._oid, "frame_code", (self._fid,), {}) return CodeProxy(self._conn, self._oid, cid) def _get_f_globals(self): did = self._conn.remotecall(self._oid, "frame_globals", (self._fid,), {}) return self._get_dict_proxy(did) def _get_f_locals(self): did = self._conn.remotecall(self._oid, "frame_locals", (self._fid,), {}) return self._get_dict_proxy(did) def _get_dict_proxy(self, did): if self._dictcache.has_key(did): return self._dictcache[did] dp = DictProxy(self._conn, self._oid, did) self._dictcache[did] = dp return dp class CodeProxy: def __init__(self, conn, oid, cid): self._conn = conn self._oid = oid self._cid = cid def __getattr__(self, name): if name == "co_name": return self._conn.remotecall(self._oid, "code_name", (self._cid,), {}) if name == "co_filename": return self._conn.remotecall(self._oid, "code_filename", (self._cid,), {}) class DictProxy: def __init__(self, conn, oid, did): self._conn = conn self._oid = oid self._did = did def keys(self): return self._conn.remotecall(self._oid, "dict_keys", (self._did,), {}) def __getitem__(self, key): return self._conn.remotecall(self._oid, "dict_item", (self._did, key), {}) def __getattr__(self, name): ##print >>sys.__stderr__, "failed DictProxy.__getattr__:", name raise AttributeError, name class GUIAdaper: def __init__(self, conn, gui): self.conn = conn self.gui = gui def interaction(self, message, fid, iid): print "interaction(%s, %s, %s)" % (`message`, `fid`, `iid`) frame = FrameProxy(self.conn, fid) info = None # XXX for now self.gui.interaction(message, frame, info) class IdbProxy: def __init__(self, conn, oid): self.oid = oid self.conn = conn def call(self, methodname, *args, **kwargs): ##print "call %s %s %s" % (methodname, args, kwargs) value = self.conn.remotecall(self.oid, methodname, args, kwargs) ##print "return %s" % `value` return value def run(self, cmd, locals): # Ignores locals on purpose! self.call("run", cmd) def get_stack(self, frame, tb): stack, i = self.call("get_stack", frame._fid, None) stack = [(FrameProxy(self.conn, fid), k) for fid, k in stack] return stack, i def set_continue(self): self.call("set_continue") def set_step(self): self.call("set_step") def set_next(self, frame): self.call("set_next", frame._fid) def set_return(self, frame): self.call("set_return", frame._fid) def set_quit(self): self.call("set_quit") def start_remote_debugger(conn, pyshell): # # instruct the (remote) subprocess to create # a debugger instance, and lets it know that # the local GUIAdapter called "gui_adapter" # is waiting notification of debugging events # ada_oid = "gui_adapter" idb_oid = conn.remotecall("exec", "start_debugger", (ada_oid,), {}) idb = IdbProxy(conn, idb_oid) gui = Debugger.Debugger(pyshell, idb) ada = GUIAdaper(conn, gui) conn.register(ada_oid, ada) return gui --- NEW FILE: rpc.py --- # ASCII-art documentation # # +---------------------------------+ +----------+ # | SocketServer.BaseRequestHandler | | SocketIO | # +---------------------------------+ +----------+ # ^ ^ ^ # | | | # | + -------------------+ | # | | | # +-------------------------+ +-----------------+ # | RPCHandler | | RPCClient | # |-------------------------| |-----------------| # | register() | | remotecall() | # | unregister() | | register() | # | | | unregister() | # | | | get_remote_proxy| # +-------------------------+ +-----------------+ # import sys import socket import select import SocketServer import struct import cPickle as pickle import threading import traceback import copy_reg import types import marshal def unpickle_code(ms): co = marshal.loads(ms) assert isinstance(co, types.CodeType) return co def pickle_code(co): assert isinstance(co, types.CodeType) ms = marshal.dumps(co) return unpickle_code, (ms,) def unpickle_function(ms): return ms def pickle_function(fn): assert isinstance(fn, type.FunctionType) return `fn` copy_reg.pickle(types.CodeType, pickle_code, unpickle_code) copy_reg.pickle(types.FunctionType, pickle_function, unpickle_function) BUFSIZE = 8*1024 class RPCServer(SocketServer.TCPServer): def __init__(self, addr, handlerclass=None): if handlerclass is None: handlerclass = RPCHandler self.objtable = objecttable SocketServer.TCPServer.__init__(self, addr, handlerclass) def verify_request(self, request, client_address): host, port = client_address if host != "127.0.0.1": print "Disallowed host:", host return 0 else: return 1 def register(self, oid, object): self.objtable[oid] = object def unregister(self, oid): try: del self.objtable[oid] except KeyError: pass objecttable = {} class SocketIO: debugging = 0 def __init__(self, sock, objtable=None, debugging=None): self.mainthread = threading.currentThread() if debugging is not None: self.debugging = debugging self.sock = sock if objtable is None: objtable = objecttable self.objtable = objtable self.statelock = threading.Lock() self.responses = {} self.cvars = {} def close(self): sock = self.sock self.sock = None if sock is not None: sock.close() def debug(self, *args): if not self.debugging: return s = str(threading.currentThread().getName()) for a in args: s = s + " " + str(a) s = s + "\n" sys.__stderr__.write(s) def register(self, oid, object): self.objtable[oid] = object def unregister(self, oid): try: del self.objtable[oid] except KeyError: pass def localcall(self, request): ##self.debug("localcall:", request) try: how, (oid, methodname, args, kwargs) = request except TypeError: return ("ERROR", "Bad request format") assert how == "call" if not self.objtable.has_key(oid): return ("ERROR", "Unknown object id: %s" % `oid`) obj = self.objtable[oid] if methodname == "__methods__": methods = {} _getmethods(obj, methods) return ("OK", methods) if methodname == "__attributes__": attributes = {} _getattributes(obj, attributes) return ("OK", attributes) if not hasattr(obj, methodname): return ("ERROR", "Unsupported method name: %s" % `methodname`) method = getattr(obj, methodname) try: ret = method(*args, **kwargs) if isinstance(ret, RemoteObject): ret = remoteref(ret) return ("OK", ret) except: ##traceback.print_exc(file=sys.__stderr__) typ, val, tb = info = sys.exc_info() sys.last_type, sys.last_value, sys.last_traceback = info if isinstance(typ, type(Exception)): # Class exceptions mod = typ.__module__ name = typ.__name__ if issubclass(typ, Exception): args = val.args else: args = (str(val),) else: # String exceptions mod = None name = typ args = (str(val),) tb = traceback.extract_tb(tb) return ("EXCEPTION", (mod, name, args, tb)) def remotecall(self, oid, methodname, args, kwargs): seq = self.asynccall(oid, methodname, args, kwargs) return self.asyncreturn(seq) def asynccall(self, oid, methodname, args, kwargs): request = ("call", (oid, methodname, args, kwargs)) seq = self.putrequest(request) return seq def asyncreturn(self, seq): response = self.getresponse(seq) return self.decoderesponse(response) def decoderesponse(self, response): how, what = response if how == "OK": return what if how == "EXCEPTION": mod, name, args, tb = what self.traceback = tb if mod: try: __import__(mod) module = sys.modules[mod] except ImportError: pass else: try: cls = getattr(module, name) except AttributeError: pass else: raise getattr(__import__(mod), name)(*args) else: if mod: name = mod + "." + name raise name, args if how == "ERROR": raise RuntimeError, what raise SystemError, (how, what) def mainloop(self): try: self.getresponse(None) except EOFError: pass def getresponse(self, myseq): response = self._getresponse(myseq) if response is not None: how, what = response if how == "OK": response = how, self._proxify(what) return response def _proxify(self, obj): if isinstance(obj, RemoteProxy): return RPCProxy(self, obj.oid) if isinstance(obj, types.ListType): return map(self._proxify, obj) # XXX Check for other types -- not currently needed return obj def _getresponse(self, myseq): if threading.currentThread() is self.mainthread: # Main thread: does all reading of requests and responses while 1: response = self.pollresponse(myseq, None) if response is not None: return response else: # Auxiliary thread: wait for notification from main thread cvar = threading.Condition(self.statelock) self.statelock.acquire() self.cvars[myseq] = cvar while not self.responses.has_key(myseq): cvar.wait() response = self.responses[myseq] del self.responses[myseq] del self.cvars[myseq] self.statelock.release() return response def putrequest(self, request): seq = self.newseq() self.putmessage((seq, request)) return seq nextseq = 0 def newseq(self): self.nextseq = seq = self.nextseq + 2 return seq def putmessage(self, message): try: s = pickle.dumps(message) except: print >>sys.__stderr__, "Cannot pickle:", `message` raise s = struct.pack(" 0: n = self.sock.send(s) s = s[n:] def ioready(self, wait=0.0): r, w, x = select.select([self.sock.fileno()], [], [], wait) return len(r) buffer = "" bufneed = 4 bufstate = 0 # meaning: 0 => reading count; 1 => reading data def pollpacket(self, wait=0.0): self._stage0() if len(self.buffer) < self.bufneed: if not self.ioready(wait): return None try: s = self.sock.recv(BUFSIZE) except socket.error: raise EOFError if len(s) == 0: raise EOFError self.buffer += s self._stage0() return self._stage1() def _stage0(self): if self.bufstate == 0 and len(self.buffer) >= 4: s = self.buffer[:4] self.buffer = self.buffer[4:] self.bufneed = struct.unpack("= self.bufneed: packet = self.buffer[:self.bufneed] self.buffer = self.buffer[self.bufneed:] self.bufneed = 4 self.bufstate = 0 return packet def pollmessage(self, wait=0.0): packet = self.pollpacket(wait) if packet is None: return None try: message = pickle.loads(packet) except: print >>sys.__stderr__, "-----------------------" print >>sys.__stderr__, "cannot unpickle packet:", `packet` traceback.print_stack(file=sys.__stderr__) print >>sys.__stderr__, "-----------------------" raise return message def pollresponse(self, myseq, wait=0.0): # Loop while there's no more buffered input or until specific response while 1: message = self.pollmessage(wait) if message is None: return None wait = 0.0 seq, resq = message if resq[0] == "call": response = self.localcall(resq) self.putmessage((seq, response)) continue elif seq == myseq: return resq else: self.statelock.acquire() self.responses[seq] = resq cv = self.cvars.get(seq) if cv is not None: cv.notify() self.statelock.release() continue class RemoteObject: # Token mix-in class pass def remoteref(obj): oid = id(obj) objecttable[oid] = obj return RemoteProxy(oid) class RemoteProxy: def __init__(self, oid): self.oid = oid class RPCHandler(SocketServer.BaseRequestHandler, SocketIO): debugging = 0 def __init__(self, sock, addr, svr): svr.current_handler = self ## cgt xxx SocketIO.__init__(self, sock) SocketServer.BaseRequestHandler.__init__(self, sock, addr, svr) def setup(self): SocketServer.BaseRequestHandler.setup(self) print >>sys.__stderr__, "Connection from", self.client_address def finish(self): print >>sys.__stderr__, "End connection from", self.client_address SocketServer.BaseRequestHandler.finish(self) def handle(self): self.mainloop() def get_remote_proxy(self, oid): return RPCProxy(self, oid) class RPCClient(SocketIO): nextseq = 1 # Requests coming from the client are odd def __init__(self, address, family=socket.AF_INET, type=socket.SOCK_STREAM): sock = socket.socket(family, type) sock.connect(address) SocketIO.__init__(self, sock) def get_remote_proxy(self, oid): return RPCProxy(self, oid) class RPCProxy: __methods = None __attributes = None def __init__(self, sockio, oid): self.sockio = sockio self.oid = oid def __getattr__(self, name): if self.__methods is None: self.__getmethods() if self.__methods.get(name): return MethodProxy(self.sockio, self.oid, name) if self.__attributes is None: self.__getattributes() if not self.__attributes.has_key(name): raise AttributeError, name __getattr__.DebuggerStepThrough=1 def __getattributes(self): self.__attributes = self.sockio.remotecall(self.oid, "__attributes__", (), {}) def __getmethods(self): self.__methods = self.sockio.remotecall(self.oid, "__methods__", (), {}) def _getmethods(obj, methods): # Helper to get a list of methods from an object # Adds names to dictionary argument 'methods' for name in dir(obj): attr = getattr(obj, name) if callable(attr): methods[name] = 1 if type(obj) == types.InstanceType: _getmethods(obj.__class__, methods) if type(obj) == types.ClassType: for super in obj.__bases__: _getmethods(super, methods) def _getattributes(obj, attributes): for name in dir(obj): attr = getattr(obj, name) if not callable(attr): attributes[name] = 1 class MethodProxy: def __init__(self, sockio, oid, name): self.sockio = sockio self.oid = oid self.name = name def __call__(self, *args, **kwargs): value = self.sockio.remotecall(self.oid, self.name, args, kwargs) return value # # Self Test # def testServer(addr): class RemotePerson: def __init__(self,name): self.name = name def greet(self, name): print "(someone called greet)" print "Hello %s, I am %s." % (name, self.name) print def getName(self): print "(someone called getName)" print return self.name def greet_this_guy(self, name): print "(someone called greet_this_guy)" print "About to greet %s ..." % name remote_guy = self.server.current_handler.get_remote_proxy(name) remote_guy.greet("Thomas Edison") print "Done." print person = RemotePerson("Thomas Edison") svr = RPCServer(addr) svr.register('thomas', person) person.server = svr # only required if callbacks are used # svr.serve_forever() svr.handle_request() # process once only def testClient(addr): # # demonstrates RPC Client # import time clt=RPCClient(addr) thomas = clt.get_remote_proxy("thomas") print "The remote person's name is ..." print thomas.getName() # print clt.remotecall("thomas", "getName", (), {}) print time.sleep(1) print "Getting remote thomas to say hi..." thomas.greet("Alexander Bell") #clt.remotecall("thomas","greet",("Alexander Bell",), {}) print "Done." print time.sleep(2) # demonstrates remote server calling local instance class LocalPerson: def __init__(self,name): self.name = name def greet(self, name): print "You've greeted me!" def getName(self): return self.name person = LocalPerson("Alexander Bell") clt.register("alexander",person) thomas.greet_this_guy("alexander") # clt.remotecall("thomas","greet_this_guy",("alexander",), {}) def test(): addr=("localhost",8833) if len(sys.argv) == 2: if sys.argv[1]=='-server': testServer(addr) return testClient(addr) if __name__ == '__main__': test() --- NEW FILE: run.py --- import sys import rpc def main(): port = 8833 if sys.argv[1:]: port = int(sys.argv[1]) sys.argv[:] = [""] addr = ("localhost", port) svr = rpc.RPCServer(addr, MyHandler) svr.handle_request() # A single request only class MyHandler(rpc.RPCHandler): def handle(self): executive = Executive(self) self.register("exec", executive) sys.stdin = self.get_remote_proxy("stdin") sys.stdout = self.get_remote_proxy("stdout") sys.stderr = self.get_remote_proxy("stderr") rpc.RPCHandler.handle(self) class Executive: def __init__(self, rpchandler): self.conn = rpchandler import __main__ self.locals = __main__.__dict__ def runcode(self, code): exec code in self.locals def start_debugger(self, gui_oid): import RemoteDebugger return RemoteDebugger.start_debugger(self.conn, gui_oid) def stackviewer(self, flist_oid=None): if not hasattr(sys, "last_traceback"): return None flist = None if flist_oid is not None: flist = self.conn.get_remote_proxy(flist_oid) import RemoteObjectBrowser import StackViewer tb = sys.last_traceback while tb and tb.tb_frame.f_globals["__name__"] in ["rpc", "run"]: tb = tb.tb_next item = StackViewer.StackTreeItem(flist, tb) return RemoteObjectBrowser.remote_object_tree_item(item) Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** ScriptBinding.py 19 Jan 2002 10:41:51 -0000 1.4 --- ScriptBinding.py 26 May 2002 13:36:40 -0000 1.5 *************** *** 15,18 **** --- 15,26 ---- code in the __main__ namespace. + XXX Redesign this interface (yet again) as follows: + + - Present a dialog box for ``Run script'' + + - Allow specify command line arguments in the dialog box + + - Restart the interpreter when running a script + """ *************** *** 26,32 **** This means that either: ! (1) your indentation is outright incorrect (easy to fix), or ! (2) your indentation mixes tabs and spaces in a way that depends on \ how many spaces a tab is worth. --- 34,40 ---- This means that either: ! 1) your indentation is outright incorrect (easy to fix), or ! 2) your indentation mixes tabs and spaces in a way that depends on \ how many spaces a tab is worth. *************** *** 106,109 **** --- 114,121 ---- def import_module_event(self, event): + flist = self.editwin.flist + shell = flist.open_shell() + interp = shell.interp + filename = self.getfilename() if not filename: *************** *** 111,131 **** modname, ext = os.path.splitext(os.path.basename(filename)) - if sys.modules.has_key(modname): - mod = sys.modules[modname] - else: - mod = imp.new_module(modname) - sys.modules[modname] = mod - mod.__file__ = filename - setattr(sys.modules['__main__'], modname, mod) dir = os.path.dirname(filename) dir = os.path.normpath(os.path.abspath(dir)) - if dir not in sys.path: - sys.path.insert(0, dir) ! flist = self.editwin.flist ! shell = flist.open_shell() ! interp = shell.interp ! interp.runcode("reload(%s)" % modname) def run_script_event(self, event): --- 123,142 ---- modname, ext = os.path.splitext(os.path.basename(filename)) dir = os.path.dirname(filename) dir = os.path.normpath(os.path.abspath(dir)) ! interp.runcode("""if 1: ! import sys as _sys ! if %s not in _sys.path: ! _sys.path.insert(0, %s) ! if _sys.modules.get(%s): ! del _sys ! import %s ! reload(%s) ! else: ! del _sys ! import %s ! \n""" % (`dir`, `dir`, `modname`, modname, modname, modname)) def run_script_event(self, event): *************** *** 137,144 **** shell = flist.open_shell() interp = shell.interp ! if (not sys.argv or ! os.path.basename(sys.argv[0]) != os.path.basename(filename)): ! # XXX Too often this discards arguments the user just set... ! sys.argv = [filename] interp.execfile(filename) --- 148,161 ---- shell = flist.open_shell() interp = shell.interp ! # XXX Too often this discards arguments the user just set... ! interp.runcommand("""if 1: ! _filename = %s ! import sys as _sys ! from os.path import basename as _basename ! if (not _sys.argv or ! _basename(_sys.argv[0]) != _basename(_filename)): ! _sys.argv = [_filename] ! del _filename, _sys, _basename ! \n""" % `filename`) interp.execfile(filename) Index: Debugger.py =================================================================== RCS file: /cvsroot/idlefork/idle/Debugger.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** Debugger.py 25 Feb 2002 23:22:08 -0000 1.4 --- Debugger.py 26 May 2002 13:36:40 -0000 1.5 *************** *** 1,4 **** --- 1,5 ---- import os import bdb + import types import traceback from Tkinter import * *************** *** 8,25 **** ! class Debugger(bdb.Bdb): - interacting = 0 vstack = vsource = vlocals = vglobals = None ! def __init__(self, pyshell): ! bdb.Bdb.__init__(self) self.pyshell = pyshell self.make_gui() ! def canonic(self, filename): ! # Canonicalize filename -- called by Bdb ! return os.path.normcase(os.path.abspath(filename)) def close(self, event=None): --- 9,72 ---- ! class Idb(bdb.Bdb): ! ! def __init__(self, gui): ! self.gui = gui ! bdb.Bdb.__init__(self) ! ! def user_line(self, frame): ! # get the currently executing function ! co_filename = frame.f_code.co_filename ! co_name = frame.f_code.co_name ! try: ! func = frame.f_locals[co_name] ! if getattr(func, "DebuggerStepThrough", 0): ! print "XXXX DEBUGGER STEPPING THROUGH" ! self.set_step() ! return ! except: ! pass ! if co_filename in ('rpc.py', ''): ! self.set_step() ! return ! if co_filename.endswith('threading.py'): ! self.set_step() ! return ! message = self.__frame2message(frame) ! self.gui.interaction(message, frame) ! ! def user_exception(self, frame, info): ! message = self.__frame2message(frame) ! self.gui.interaction(message, frame, info) ! ! def __frame2message(self, frame): ! code = frame.f_code ! filename = code.co_filename ! lineno = frame.f_lineno ! basename = os.path.basename(filename) ! message = "%s:%s" % (basename, lineno) ! if code.co_name != "?": ! message = "%s: %s()" % (message, code.co_name) ! return message + class Debugger: + + interacting = 0 vstack = vsource = vlocals = vglobals = None ! def __init__(self, pyshell, idb=None): ! if idb is None: ! idb = Idb(self) self.pyshell = pyshell + self.idb = idb self.make_gui() ! def run(self, *args): ! try: ! self.interacting = 1 ! return self.idb.run(*args) ! finally: ! self.interacting = 0 def close(self, event=None): *************** *** 32,53 **** self.top.destroy() - def run(self, *args): - try: - self.interacting = 1 - return apply(bdb.Bdb.run, (self,) + args) - finally: - self.interacting = 0 - - def user_line(self, frame): - self.interaction(frame) - - def user_return(self, frame, rv): - # XXX show rv? - ##self.interaction(frame) - pass - - def user_exception(self, frame, info): - self.interaction(frame, info) - def make_gui(self): pyshell = self.pyshell --- 79,82 ---- *************** *** 129,142 **** frame = None ! def interaction(self, frame, info=None): self.frame = frame - code = frame.f_code - file = code.co_filename - base = os.path.basename(file) - lineno = frame.f_lineno - # - message = "%s:%s" % (base, lineno) - if code.co_name != "?": - message = "%s: %s()" % (message, code.co_name) self.status.configure(text=message) # --- 158,163 ---- frame = None ! def interaction(self, message, frame, info=None): self.frame = frame self.status.configure(text=message) # *************** *** 161,165 **** sv = self.stackviewer if sv: ! stack, i = self.get_stack(self.frame, tb) sv.load_stack(stack, i) # --- 182,186 ---- sv = self.stackviewer if sv: ! stack, i = self.idb.get_stack(self.frame, tb) sv.load_stack(stack, i) # *************** *** 185,214 **** if not frame: return code = frame.f_code ! file = code.co_filename lineno = frame.f_lineno ! if file[:1] + file[-1:] != "<>" and os.path.exists(file): ! edit = self.flist.open(file) ! if edit: ! edit.gotoline(lineno) def cont(self): ! self.set_continue() self.root.quit() def step(self): ! self.set_step() self.root.quit() def next(self): ! self.set_next(self.frame) self.root.quit() def ret(self): ! self.set_return(self.frame) self.root.quit() def quit(self): ! self.set_quit() self.root.quit() --- 206,237 ---- if not frame: return + filename, lineno = self.__frame2fileline(frame) + if filename[:1] + filename[-1:] != "<>" and os.path.exists(filename): + self.flist.gotofileline(filename, lineno) + + def __frame2fileline(self, frame): code = frame.f_code ! filename = code.co_filename lineno = frame.f_lineno ! return filename, lineno def cont(self): ! self.idb.set_continue() self.root.quit() def step(self): ! self.idb.set_step() self.root.quit() def next(self): ! self.idb.set_next(self.frame) self.root.quit() def ret(self): ! self.idb.set_return(self.frame) self.root.quit() def quit(self): ! self.idb.set_quit() self.root.quit() *************** *** 220,224 **** self.fstack, self.flist, self) if self.frame: ! stack, i = self.get_stack(self.frame, None) sv.load_stack(stack, i) else: --- 243,247 ---- self.fstack, self.flist, self) if self.frame: ! stack, i = self.idb.get_stack(self.frame, None) sv.load_stack(stack, i) else: *************** *** 234,237 **** --- 257,261 ---- def show_frame(self, (frame, lineno)): + # Called from OldStackViewer self.frame = frame self.show_variables() *************** *** 296,309 **** # A literal copy of Bdb.set_break() without the print statement at the end ! def set_break(self, filename, lineno, temporary=0, cond = None): ! import linecache # Import as late as possible ! filename = self.canonic(filename) ! line = linecache.getline(filename, lineno) ! if not line: ! return 'That line does not exist!' ! if not self.breaks.has_key(filename): ! self.breaks[filename] = [] ! list = self.breaks[filename] ! if not lineno in list: ! list.append(lineno) ! bp = bdb.Breakpoint(filename, lineno, temporary, cond) --- 320,333 ---- # A literal copy of Bdb.set_break() without the print statement at the end ! #def set_break(self, filename, lineno, temporary=0, cond = None): ! # import linecache # Import as late as possible ! # filename = self.canonic(filename) ! # line = linecache.getline(filename, lineno) ! # if not line: ! # return 'That line does not exist!' ! # if not self.breaks.has_key(filename): ! # self.breaks[filename] = [] ! # list = self.breaks[filename] ! # if not lineno in list: ! # list.append(lineno) ! # bp = bdb.Breakpoint(filename, lineno, temporary, cond) Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -r1.13 -r1.14 *** PyShell.py 27 Mar 2002 00:51:53 -0000 1.13 --- PyShell.py 26 May 2002 13:36:41 -0000 1.14 *************** *** 1,908 **** ! #! /usr/bin/env python ! ! # changes by dscherer@cmu.edu ! ! # The main() function has been replaced by a whole class, in order to ! # address the constraint that only one process can sit on the port ! # hard-coded into the loader. ! ! # It attempts to load the RPC protocol server and publish itself. If ! # that fails, it assumes that some other copy of IDLE is already running [...1958 lines suppressed...] ! interp.execfile(filename) ! ! if debug: ! shell.open_debugger() ! if cmd: ! interp.execsource(cmd) ! elif script: ! if os.path.isfile(script): ! interp.execfile(script) ! else: ! print "No script file: ", script ! shell.begin() ! ! self.idle() ! root.mainloop() ! root.destroy() ! ! ! if __name__ == "__main__": ! main() From s997659@ee.cuhk.edu.hk Mon May 27 05:24:33 2002 From: s997659@ee.cuhk.edu.hk (Geiger Ho) Date: Mon, 27 May 2002 12:24:33 +0800 (HKT) Subject: [Idle-dev] Code comment Message-ID: Hi all, In the codes obtaining from 0.8.1, TreeWidget.py, line 190, child = TreeNode(self.canvas, self, item) Could it be changed to: child = self.__class__(self.canvas, self, item) I think out of this change because when I want to derive from class TreeNode, I need to override the draw() method in my derived class as well. Thanks. Regards, Geiger From guido@python.org Mon May 27 14:41:10 2002 From: guido@python.org (Guido van Rossum) Date: Mon, 27 May 2002 09:41:10 -0400 Subject: [Idle-dev] Code comment In-Reply-To: Your message of "Mon, 27 May 2002 12:24:33 +0800." References: Message-ID: <200205271341.g4RDfAn02033@pcp742651pcs.reston01.va.comcast.net> > In the codes obtaining from 0.8.1, TreeWidget.py, line 190, > > child = TreeNode(self.canvas, self, item) > > Could it be changed to: > > child = self.__class__(self.canvas, self, item) > > I think out of this change because when I want to derive from class > TreeNode, I need to override the draw() method in my derived class as > well. Good idea! I've applied this to the Python branch of IDLE; someone else please apply to to IDLEFORK. --Guido van Rossum (home page: http://www.python.org/~guido/) From elguavas@users.sourceforge.net Mon May 27 22:58:08 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Mon, 27 May 2002 14:58:08 -0700 Subject: [Idle-dev] CVS: idle TreeWidget.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv11393 Modified Files: TreeWidget.py Log Message: Geiger Ho's patch for better sunclassing Index: TreeWidget.py =================================================================== RCS file: /cvsroot/idlefork/idle/TreeWidget.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** TreeWidget.py 4 Jul 2001 03:15:10 -0000 1.2 --- TreeWidget.py 27 May 2002 21:58:05 -0000 1.3 *************** *** 188,192 **** return y+17 for item in sublist: ! child = TreeNode(self.canvas, self, item) self.children.append(child) cx = x+20 --- 188,192 ---- return y+17 for item in sublist: ! child = self.__class__(self.canvas, self, item) self.children.append(child) cx = x+20 From elguavas@users.sourceforge.net Mon May 27 23:00:28 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 28 May 2002 08:00:28 +1000 Subject: [Idle-dev] Code comment In-Reply-To: <200205271341.g4RDfAn02033@pcp742651pcs.reston01.va.comcast.net> References: <200205271341.g4RDfAn02033@pcp742651pcs.reston01.va.comcast.net> Message-ID: <1022536829.505.0.camel@oberon> > > I think out of this change because when I want to derive from class > > TreeNode, I need to override the draw() method in my derived class as > > well. > > Good idea! I've applied this to the Python branch of IDLE; someone > else please apply to to IDLEFORK. Done. Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From elguavas@users.sourceforge.net Mon May 27 23:21:24 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 28 May 2002 08:21:24 +1000 Subject: [Idle-dev] CVS: idle TreeWidget.py,1.2,1.3 In-Reply-To: References: Message-ID: <1022538085.2071.5.camel@oberon> > Log Message: > Geiger Ho's patch for better sunclassing Hmmm. I used cvs admin to correct that to "subclassing". I don't spell well before breakfast. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From elguavas@users.sourceforge.net Mon May 27 23:20:01 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 28 May 2002 08:20:01 +1000 Subject: [Idle-dev] CVS: idle TreeWidget.py,1.2,1.3 In-Reply-To: References: Message-ID: <1022538001.2070.2.camel@oberon> > Log Message: > Geiger Ho's patch for better sunclassing Hmmm. I used cvs admin to correct that to "subclassing". I don't spell well before breakfast. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy " From kbk@shore.net Thu May 30 19:55:50 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 30 May 2002 14:55:50 -0400 Subject: [Idle-dev] ildlefork - developer list Message-ID: Back on May 21 I sent the following email to Stephen: > Hi, > > Although I have been tied up for the past few months, I'm now coming > out the other side. I continue to have an interest in contributing to > Idlefork as a developer, and expect to have more time available to do > so. > > Please restore my permissions to the project. Thanks. > > Regards, KBK I have not heard anything back, so perhaps it fell afoul of the spam filters or my ISP's somewhat erratic outgoing mail validation and relay. Let me try again. As I said in the email, I now have more time available than in the past nine months. As a matter of fact, I had spent quite a bit of time recently studying the rpc codes and Idle in general. There is quite a bit to absorb, and one doesn't want to just jump in and muck around without understanding the implementation. Regards, KBK From elguavas@users.sourceforge.net Fri May 31 01:04:38 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: 31 May 2002 10:04:38 +1000 Subject: [Idle-dev] ildlefork - developer list In-Reply-To: References: Message-ID: <1022803478.944.14.camel@oberon> > Back on May 21 I sent the following email to Stephen: > > > Hi, > > > > Although I have been tied up for the past few months, I'm now coming > > out the other side. I continue to have an interest in contributing to > > Idlefork as a developer, and expect to have more time available to do > > so. > > > > Please restore my permissions to the project. Thanks. > > > > Regards, KBK > > I have not heard anything back, so perhaps it fell afoul of the spam > filters or my ISP's somewhat erratic outgoing mail validation and > relay. Let me try again. Hi Kurt, no, I didn't receive the above message at all... I've cc'd this reply to idle-dev to make sure you get it. I just added you back as a developer on the project, welcome back aboard. I'll email you in more detail later when I get a chance to update you on what the current state of play is, what everyone is working on etc.. Please let me know if my message got through to your personal email address, preferably by mailing me directly again to see if you get through this time. I'd rather we didn't have to clog up the list with project administrivia, if possible. Regards, Stephen. -- Stephen M. Gava IDLEfork ( http://idlefork.sourceforge.net ) " just like IDLE, only crunchy "