From stephenm@humongous.com Sat Jun 1 22:05:32 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Sat, 1 Jun 2002 14:05:32 -0700 Subject: [Pythonmac-SIG] _environ using python as a bundled library Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE76B@sea-horse.humongous.com> I am trying to use Python as a bundled library within another library using the Metrowerks compiler. When I try to link a project that that includes the Python bundle I get a link error, _environ is undefined. Anyone know how to work around this? _environ is part of crt1.o, used for apps and it has _environ, but that doesn't help me. Back in February, Jack asked a very similar question, though I don't see a solution posted. Is there one? From Jack.Jansen@oratrix.com Sat Jun 1 23:36:38 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 2 Jun 2002 00:36:38 +0200 Subject: [Pythonmac-SIG] _environ using python as a bundled library In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE76B@sea-horse.humongous.com> Message-ID: <094E347E-75B0-11D6-B9FC-003065517236@oratrix.com> On zaterdag, juni 1, 2002, at 11:05 , Magladry, Stephen wrote: > I am trying to use Python as a bundled library within another > library using > the Metrowerks compiler. When I try to link a project that that > includes the > Python bundle I get a link error, _environ is undefined. Anyone > know how to > work around this? > > _environ is part of crt1.o, used for apps and it has _environ, but that > doesn't help me. > > Back in February, Jack asked a very similar question, though I > don't see a > solution posted. Is there one? The problem was fixed, but I can't for the life of me remember how.... What Python version are you using? Could you try checking out the CVS python, and see whether the problem is fixed there? You are using the framework Python, I assume, not a .so-based Python without frameworks? This hasn't been tested at all really, so you would be on your own then... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gherman@darwin.in-berlin.de Mon Jun 3 12:06:14 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 03 Jun 2002 13:06:14 +0200 (CEST) Subject: [Pythonmac-SIG] Python, Jython, Cocoa and Charleroi Message-ID: <1023102374.3cfb4da6e6630@webmail.in-berlin.de> Hi, is anybody here interested in Python and Cocoa going to Charleroi? I'd be interested to share some experience with others... It's not enough for a full presentation, but what I did is basically try to use Jython to write Python application code with access to Apple's Cocoa frameworks, i.e. the Foundation and AppKit. While I do think this is promising, I also have some difficulties working with so- called selectors, delegate callbacks and loading NIB files... Regards, Dinu From oussoren@cistron.nl Mon Jun 3 14:21:06 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Mon, 3 Jun 2002 15:21:06 +0200 Subject: [Pythonmac-SIG] Python, Jython, Cocoa and Charleroi Message-ID: Dinu Gherman wrote: > is anybody here interested in Python and Cocoa going to Charleroi? I'm definitely interested in Python and Cocoa, but not going to Chareroi. How are Jython and Cocoa working out? We (Frans Schippers, Jack Jansen and myself) are working on calling Cocoa from CPython, using the pyobjc module as a starting point. Loading NIB files works just fine, connecting the NIB to python will require some work. Ronald From phoengeist38259@arcor.de" Entschuldigen Sie bitte die Störung! Mir ist etwas zu Ohren gekommen. Eine relativ aussergewöhnliche Gerüchteküche, aus der man mir ein schwerverdauliches Süppchen vorgesetzt hat, ist der Grund meiner Mail. Unappetitlich ist gar kein Ausdruck! Ist es möglich auf funktechnischem Wege(in welchen Frequenzbereichen?) jemanden zu beeinflussen oder zu manipulieren? Oder sogar zu schikanieren und terrorisieren? Unter dem Motto:"Einen am Sender?Nich ganz alleine? Kleine Mannim Ohr?Falsche Wellenlänge?Bohnen in den Ohren? Auf den Zahn gefühlt(Amalgam)?Mal unverbindlich reinhören? Der Pullacher Wanzentanz? Ist das Spinnerei?Das geht doch gar nicht,oder? Und wenn wie sieht das ethisch moralisch aus? Zur technischen Seite der Sache gibt es zwar Berichte und Webseiten: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. ,aber,das kann doch nicht sein,das soetwas gemacht wird,oder? Eine Menschenrechtsverletzung sonder gleichen!?! Ist es möglich,durch Präparation,der Ohren und im Zusammenspiel mit eventuell vorhandenem Zahnersatz? Mit relativ einfacher Funktechnik?? In diesem Land?Hier und heute??? Unter welchen Motiven? Wo ist eigentlich die Abteilung 5 des BND und des Verfassungsschutzes? Kann es sein,daß es Leute gibt,die dem BND/Verfassungsschutz,auf funktechnischem Wege permanent einen Situationsbericht abliefern,ohne es selbst zu merken,im Kindesalter machbar gemacht?? Werden durch solche inoffiziellen Mitarbeiter,beim BND und Verfassungsschutz,nach Stasimanier, Informationen von und über,rein theoretisch, jeden Bundesbürger,gesammelt? Gibt es dann noch ein Recht auf Privatsphere? Wer kontrolliert eigentlich den BND,MAD und Verfassungsschutz auf Unterwanderung??? In der Mail geht es mir eigentlich um die Frage,ob es kriminellen Elementen, aus dem Motiv der Bereicherung,oder Gruppierungen aus ideologischen Motiven, möglich ist ,sich Wissen und Technik anzueignen,die zu anderen Zeiten, aus anderen Motiven(Westfernsehen?),entwickelt wurde. Und stellt der technische Wissensstand, der der Allgemeinheit bekannt ist wirklich das Ende der Fahnenstange dar? Ist es denn nicht kriminellen Elementen genauso möglich, ich sage das jetzt mal verharmlost und verniedlichend, einzelne Personen oder Gruppen mit relativ einfachen Mitteln, aus welchen Motiven auch immer, auszuspionieren? Und stellt diese "Ausspioniererei" nicht einen erheblichen Eingriff in die Privatsphäre dar? Ist es möglich einzelne Personen oder Gruppen, eine Akzeptans einer gewissen Öffentlichkeit(suggeriert?), die z.B. mit Hilfe von Internetseiten,wie zum Beispiel dem "Pranger"geschaffen werden könnte, mal vorausgestzt,zu terroriesieren und oder zu schikanieren, und das in aller (suggerierten)Öffentlichkeit?Haben die Leute die da am Pranger, oder auf irgendeiner anderen Seite verunglimpft,oder gar Verleumdet werden, eigentlich eine Chance zur Gegenöffentlichkeit?Ist das nicht Rufmord? Vor einigen Jahren bin ich per Zufall auf die Seite "Der Pranger" gestoßen, damals lief das noch nicht unter dem Deckmantel der Partnervermittlung. Können sich einzelne Personen,oder Interessengemeinschaften, aus reinem Selbstzweck,solcher Seiten bedienen, um unter dem Deckmantel einer fragwürdigen Zivilkourage, durch anzetteln irgendwelcher Hetzkampagnen,eigene, ganz persöhnliche Interessen durchsetzen? Können solche Seiten zur Koordination von kriminellen machenschaften dienen? Die Frage,ist es Möglichkeit oder Unmöglichkeit,technisch und gesellschaftlich, einzelne Personen,oder auch Gruppierungen,aus einer kriminellen/ideologischen Energei heraus,zu manipulieren oder zu beeinflussen,terrorisieren oder zu schickanieren,und zwar gezielt. Zielgruppenmanipulation durch Massenmedien sind alltägliche Manipulation, der mansich,mehr oder weniger,entziehen kann. Wird das Recht auf Privatsphäre,schleichend,tiefenpsychologisch, durch Sendungen,wie,zum Beispiel "Big brother",untergraben? Sollte bei einem der Angemailten ein gewisser Wissensstand zum Thema vorhanden sein, wäre ich über Hinweise zum Thema froh. Auf der Suche nach Antworten auf meine Fragen maile ich verschiedene Adressen aus dem Internet an, und hoffe aufkonstruktive Antworten und Kritiken. Über einen Besuch auf der Seite würde ich mich freuen. Sollten Sie von mir mehrfach angeschrieben worden sein,so bitte ich Sie,mir dies zu entschuldigen, das war nicht beabsichtigt. Der Grund für meine Anonymität ist die Tatsache, daß bei derlei Fragenstellerei, verständlicherweise,schnell der Ruf nach der Psychatrie laut wird. Was auch Methode hat(ist). Sollten Sie die Mail als Belästigung empfinden, möchte ich mich hiermit dafür entschuldigen! Big brother is watching you? Excuse please the disturbance! Me something came to ears. A relatively unusual rumor kitchen, from which one put forward to me a heavydigestible soup, is the reason of my Mail. Unappetizing is no printout! Is it possible on radio Wege(in for which frequency ranges?) to influence or manipulate someone? Terrorize or to even chicane and? Under the Motto:"Einen at the Sender?Nich quite alone? Small Mannim Ohr?Fal Wellenlaenge?Bohnen in the ears? On the tooth clean-hear gefuehlt(Amalgam)?Mal witthout obligation? The Pullacher bug wanzentanz? Isn't the Spinnerei?Das goes nevertheless at all, or? And if as looks ethicalally morally? For the technical page of the thing there is to report and web page: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. but, that cannot be nevertheless, which is made soetwas, or? A violation of human rights resemble special!?! Is it possible, by preparation, the ears and in interaction with possibly available artificial dentures? With relatively simple radio engineering?? In this Land?Hier and today??? Under which motives? Where is the department actually 5 of the BND and the protection of the constitution? Can it be that there are people, which deliver the Federal Intelligence Service/protection of the constitution, on radio way permanently a situation report, without noticing it, in the infancy feasiblly made? By such unofficial coworkers, with the BND and protection of the constitution, after Stasimanier, is information collected of and over,purely theoretically, each Federal citizen? Is there then still another right to Privatsphere? Who actually checks the BND, WAD and protection of the constitution for infiltration??? Into the Mail actually concerns it to me the question whether it criminal items, from which motive of enriching, or groupings from ideological motives is possible, to acquire itself knowledge and technique which were developed at other times, from other Motiven(Westfernsehen?).And does the technical knowledge status place, to that the public admits is really the end of the flag bar? Is it not to criminal items just as possible, I legend that now times played down and does nice-end, individual persons or groups with relatively simple means, to spy from whatever motives always? And doesn't this " Ausspioniererei " represent a substantial intervention into the privatsphaere? It is possible individual persons or groups, one acceptance to of a certain Oeffentlichkeit(suggeriert?), e.g. by Internet pages, how for example the " Pranger"geschaffen could become, times vorausgestzt, to terroriesieren and or chicane, and in everything (the people suggerierten)Oeffentlichkeit?Haben there at the Pranger, or on any other page to be reviled, or slandered, actually a chance to the Gegenoeffentlichkeit?Ist that not character assassination? Some years ago I am by coincidence the page " the Pranger " encountered, at that time ran not yet under the cover of the partner switching.Itself can individual persons, or communities of interests, from pure self purpose, such pages to serve, over under the cover of a doubtful Zivilkourage, through plot any rushing campaigns, own, quite persoehnliche interests to intersperse? Can such pages serve for the co-ordination of criminal machinations? The question, is it possibility or impossibility, technically and socially, individual persons, or also groupings of manipulating or of influencing from an criminal/ideological Energei, terrorizes or to schickanieren, directed.Target group manipulation by mass media are everyday manipulation, from which, more or less, can extract itself. Does the right to privatsphaere, creeping, by transmissions become deep psychological, how, for example " Big undermine brother"? If the Angemailten should be available a certain knowledge status to the topic with one, I would be glad over notes to the topic On the search for responses to my questions maile I different addresses from the Internet on, and hope up-constructional responses and criticisms.Over an attendance on the page wuerde I are pleased.If you should have been written down by me several times, then please I you to excuse me this that was not intended. The reason for my anonymity is the fact that with such Fragenstellerei, understandably, fast after the call the Psychatrie loud becomes. Which also method hat(ist). If you should feel the Mail as annoyance, I would like to apologize hereby for it! Big is watching you? Veuillez excuser le dérangement! Moi quelque chose concernant des oreilles est venu. Une cuisine de bruit relativement inhabituelle, dont on m'a placé un Sueppchen schwerverdauliches devant, est la raison de mes Mail.Aucune expression n'est peu appétissante! Il est possible sur un Wege(in funktechnischem pour quelles réponses fréquentielles?) quelqu'un influencer ou manipuler? Ou même schikanieren et terroriser? Sous le Motto:"Einen au Sender?Nich tout à fait seulement? Petits Mannim Ohr?Falsche Wellenlaenge?Bohnen dans les oreilles? Sur la dent gefuehlt(Amalgam)?Mal non contraignant reinhoeren? Le Pullacher Wanzentanz? Le Spinnerei?Das n'est-il quand même pas du tout va, ou? Et si comme cela paraît éthiquement moralement? Au côté technique de la chose, il y a certes des rapports et des Webseiten: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. toutefois qui ne peut quand même pas être qui on fait soetwas, ou? Une violation des droits de l'homme séparer ressembler!?! Il est possible, par la préparation, des oreilles et dans l'effet avec la prothèse dentaire éventuellement existante? Avec la technique de radio relativement simple?? Dans ce Land?Hier et aujourd'hui Sous quels motifs? Où le département est-il en réalité 5 du BND et de la protection d'constitution? peut il être qu'il y a les personnes qui livrent en permanence le BND/Verfassungsschutz, de manière funktechnischem un rapport de situation, sans le remarquer le -même , dans l'enfance rendu possible?? Par de tels collaborateurs officieux, avec le BND et la protection d'constitution, après manière, des informations sont-elles rassemblées et plus de, purement théoriquement, chaque citoyen allemand? Il y a alors encore un droit à des Privatsphere? Qui contrôle en réalité le BND, mad et protection d'constitution sur une infiltration??? Il s'agit en réalité dans le Mail me la question de savoir si lui éléments criminels, dont le motif de l'enrichissement, ou de groupements des motifs idéologiques, possible de s'acquérir le savoir et la technique qui à d'autres temps, est autre MotivenEt place-t-il le savoir technique dont le public vraiment la fin la barre de drapeau a connaissance ? Il n'est pas donc exactement la même chose possible pour des éléments criminels, moi cela maintenant fois verharmlost et minimisant une légende, personnes ou groupes particuliers avec des moyens relativement simples, de quels motifs aussi toujours, auszuspionieren?(Westfernsehen?), a été développé. Et ce "Ausspioniererei" ne représente-t-il pas une intervention considérable dans la vie privée? Il est possible personnes ou groupes particuliers, pour certain Oeffentlichkeit(suggeriert?), celui p. ex. à l'aide des côtés Internet, comme par exemple "le Pranger"geschaffen pourrait, fois vorausgestzt schikanieren terroriesieren et ou , et qui toute (suggerierten)Oeffentlichkeit?Haben les personnes ceux là, ou d'un autre côté verunglimpft, ou on ne pas calomnie, en réalité une chance au Gegenoeffentlichkeit?Ist qui meurtre d'appel? Il y a quelques années, je ne suis pas encore par hasard sur le côté "celui" poussé, fonctionnais alors cela sous la couche de pont de l'entremise partenaire. Des personnes particulières, ou des communautés d'intérêts le peuventelles, d'un autobut pur, de tels côtés servent, sous la couche de pont d'un Zivilkourage douteux, tracent plus de des campagnes de précipitation, propres intérêts tout à fait persoehnliche entremêlent? De tels côtés peuvent-ils servir à la coordination des manoeuvres criminelles? Question, est lui possibilité ou impossibilité de manipuler ou d'influencer techniquement et socialement, particulière personnes, ou aussi groupements, criminelle/ponctuel idéologique Energei dehors, , terroriser ou schickanieren, et ce.Une manipulation de groupe cible par des masse-médias être la manipulation quotidienne qui peut extraire mansich, plus ou moins. Le droit à la vie privée est-il miné, ramment, tiefenpsychologisch, par des envois, comme, par exemple "des Big brother"? Avec un les Angemailten si un certain savoir devait exister sur le thème, je serais heureux sur des indications sur le thème.Sur la recherche des réponses à mes questions je différentes adresses maile d'Internet dessus, et espère réponses et critiques aufkonstruktive. Sur une visite du côté http://hometown.aol.de/reinerhohn38259/homepage/index.html> je me réjouirais. Si vous deviez avoir été écrit à différentes reprises par moi, je vous demande de m'excuser cela qui n'était pas envisagé. La raison de mon anonymat est le fait qu'avec telle des Fragenstellerei, l'appel devient ce qui est bien compréhensible, rapidement bruyant après le Psychatrie. Ce que la méthode a également (ist). Si vous deviez ressentir les Mail comme un ennui, je voudrais m'excuser par ceci pour cela! Big brother is watching you? From gherman@darwin.in-berlin.de Mon Jun 3 18:43:52 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 03 Jun 2002 19:43:52 +0200 (CEST) Subject: [Pythonmac-SIG] Python, Jython, Cocoa and Charleroi In-Reply-To: References: Message-ID: <1023126232.3cfbaad8807c5@webmail.in-berlin.de> Quoting Ronald Oussoren : > I'm definitely interested in Python and Cocoa, but not going to > Chareroi. How are Jython and Cocoa working out? > > We (Frans Schippers, Jack Jansen and myself) are working on calling > Cocoa from CPython, using the pyobjc module as a starting point. > Loading NIB files works just fine, connecting the NIB to python will > require some work. Jython and Cocoa could work very nicely together! Apple has an equivalent Java API for its frameworks and I find it to be more natural to use than anything pyobjc-like that I've seen so far, one reason being that it doesn't result in plenty of underscores and parantheses that seem to be needed for simulating Objective- C's method signatures in Python. Also, pyobjc development seems to be more or less stalled (?), so I've never been sure what to expect from that side in the not so distant future. I've added below some of the most simple test functions from my growing test suite just to give you an idea... Regards, Dinu from com.apple.cocoa.foundation import * from com.apple.cocoa.application import * from java.net import URL def play(self): sound = NSSound("bong.wav", 0) result = sound.play() assert result == 1 def openURL(self): url = "http://www.reportlab.com" res = NSWorkspace.sharedWorkspace().openURL(URL(url)) assert 1 def launchApplication(self): name = "Acrobat Reader 5.0" res = NSWorkspace.sharedWorkspace().launchApplication(name) assert res def beep(self): NSApplication.beep() def localizedStringForKey(self): import os myBundle = NSBundle.bundleWithPath(os.getcwd()) locString = myBundle.localizedStringForKey("Cut", None, None) expected = "Ausschneiden" assert locString == expected def mutableArray(self): myPool = NSAutoreleasePool.push() a = NSMutableArray((1, 2, 3)) assert a.objectAtIndex(0) == 1 assert a.objectAtIndex(1) == 2 assert a.objectAtIndex(2) == 3 NSAutoreleasePool.pop(myPool) def currentUserName(self): currentUserName = NSSystem.currentUserName() assert currentUserName == 'dinu' From grisha@modpython.org Tue Jun 4 20:10:09 2002 From: grisha@modpython.org (Gregory (Grisha) Trubetskoy) Date: Tue, 4 Jun 2002 15:10:09 -0400 (EDT) Subject: [Pythonmac-SIG] os x dynamic loading question Message-ID: May be someone here can give a clue to a not so OS X savvy. I'm trying to build my development version of mod_python on OS X. I build a mod_python.so using apache's apxs which is actually a wrapper around libtool. The bottom line is that mod_python.so has libpython2.2.a statically linked into it. Apache has no problems starting and loading mod_python.so, but as soon as any Python code tries to load a .so module (in my case it happens to be "import time" for time.so), the interpreter says "Failure linking new module". After a small change to dynload_next.c, I was able to get the text of the error that OS X reports, which is: ld: ./httpd Undefined symbols: /usr/local/lib/python2.2/lib-dynload/time.so undefined reference to _PyArg_Parse expected to be defined in the executable /usr/local/lib/python2.2/lib-dynload/time.so undefined reference to _PyArg_ParseTuple expected to be defined in the executable /usr/local/lib/python2.2/lib-dynload/time.so undefined reference to _PyDict_GetItemString expected to be defined in the executable /usr/local/lib/python2.2/lib-dynload/time.so undefined reference to _PyDict_SetItemString expected to be defined in the executable /usr/local/lib/python2.2/lib-dynload/time.so undefined reference to _PyErr_NoMemory expected to be defined in the executable /usr/local/lib/python2.2/lib-dynload/time.so undefined reference to _PyErr_Occurred expected to be defined in the executable etc.... Does anyone know what this means? Why can't ld see those symbols? Thanks for any help, Grisha From wtbridgman@radix.net Wed Jun 5 00:41:56 2002 From: wtbridgman@radix.net (W.T. Bridgman) Date: Tue, 4 Jun 2002 19:41:56 -0400 Subject: [Pythonmac-SIG] CVS & MacPython Scripts? Message-ID: Has anyone on this list tried to save any of their Python codes under the CVS system on OS X? I recently imported a set of codes into the CVS system and when I checked them out, MacPython no longer wanted to recognize them, returning with a dialog that they were not Python scripts. Even the MacPython icons were gone from the files. Double-checking line-ending issues seemed to make them so I could at least generate .pyc files, but could not run an actual script. Trying to force the application type as Python didn't work either. Not sure if it's important, but the CVS repository was mounted on a volume on another OS X system. I've not had any significant problems (after the initial learning curve) with my codes under Project Builder and CVS. Anyone else have any experience with this and/or other suggestions? Thanks, Tom From lists@netelligent.biz Thu Jun 6 08:33:39 2002 From: lists@netelligent.biz (lists) Date: Thu, 6 Jun 2002 09:33:39 +0200 Subject: [Pythonmac-SIG] machopython crash on MOSX Message-ID: --Apple-Mail-2--55536721 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Yo, I'm not sure wether I should post this directly to the list of enter a as bug somewhere. If it needs to be filed as a bug I'd gladly to it, if someone would be kind enough to point me to instructions on how to do it. I've just had a crash (segmentation fault) in machopython. I'm using version 2.2.1 compiled (on MOSX 10.1.4) from source and installed as a framework. I've upgraded to 10.1.5 but dunno if it's related. The crash is totally reproducible OMM. At the python prompt type: help() modules dbm It crashes while generating the list of dbm modules: --- cut help> modules dbm Here is a list of matching modules. Enter any module name to get more help. anydbm - Generic interface to all dbm clones. dbhash - Provide a (g)dbm-compatible interface to bsdhash.hashopen. dumbdbm - A dumb and slow but simple dbm clone. test.test_dbm - Test script for the dbm module test.test_dumbdbm - Test script for the dumbdbm module test.test_gdbm - Test script for the gdbm module dbm Segmentation fault --- cut I'm including the crash log below (the crash was triggered twice). HTH = tmk = --- cut Date/Time: 2002-06-06 09:24:01 +0200 OS Version: 10.1.5 (Build 5S60) Host: localhost Command: python PID: 614 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x031e8dcc Thread 0 Crashed: #0 0x031e8dcc in 0x31e8dcc #1 0x41108ab4 in call_image_init_routines #2 0x41110318 in link_in_need_modules #3 0x41111bc4 in _dyld_link_module #4 0x70015b5c in NSLinkModule #5 0x004470dc in _PyImport_GetDynLoadFunc #6 0x0043c9c8 in _PyImport_LoadDynamicModule #7 0x0043a5e0 in load_module #8 0x0043c554 in imp_load_module #9 0x003f5fb0 in PyCFunction_Call #10 0x00423ef8 in eval_frame #11 0x004253d8 in PyEval_EvalCodeEx #12 0x004269c0 in fast_function #13 0x00423ffc in eval_frame #14 0x004253d8 in PyEval_EvalCodeEx #15 0x004269c0 in fast_function #16 0x00423ffc in eval_frame #17 0x004253d8 in PyEval_EvalCodeEx #18 0x004269c0 in fast_function #19 0x00423ffc in eval_frame #20 0x004253d8 in PyEval_EvalCodeEx #21 0x004269c0 in fast_function #22 0x00423ffc in eval_frame #23 0x004253d8 in PyEval_EvalCodeEx #24 0x004269c0 in fast_function #25 0x00423ffc in eval_frame #26 0x004253d8 in PyEval_EvalCodeEx #27 0x004269c0 in fast_function #28 0x00423ffc in eval_frame #29 0x004253d8 in PyEval_EvalCodeEx #30 0x003e83a0 in function_call #31 0x003d5d30 in PyObject_Call #32 0x003dd934 in instancemethod_call #33 0x003d5d30 in PyObject_Call #34 0x003dce3c in instance_call #35 0x003d5d30 in PyObject_Call #36 0x0042702c in ext_do_call #37 0x00424198 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x003e83a0 in function_call #40 0x003d5d30 in PyObject_Call #41 0x003dd934 in instancemethod_call #42 0x003d5d30 in PyObject_Call #43 0x003dce3c in instance_call #44 0x003d5d30 in PyObject_Call #45 0x00426dcc in do_call #46 0x00424014 in eval_frame #47 0x004253d8 in PyEval_EvalCodeEx #48 0x004205bc in PyEval_EvalCode #49 0x00443480 in run_node #50 0x004421ec in PyRun_InteractiveOneFlags #51 0x00441fb4 in PyRun_InteractiveLoopFlags #52 0x00441e54 in PyRun_AnyFileExFlags #53 0x0044c650 in Py_Main #54 0x00001e1c in _start #55 0x00001c4c in start PPC Thread State: srr0: 0x031e8dcc srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x41108ac0 ctr: 0x031e8dcc mq: 0x00000000 r0: 0x41108ab4 r1: 0xbfffdf10 r2: 0x00010410 r3: 0x41146060 r4: 0x00000000 r5: 0x00000000 r6: 0x00000000 r7: 0x03115510 r8: 0x03115724 r9: 0x411463a8 r10: 0x03115000 r11: 0x00001ce8 r12: 0x031e8dcc r13: 0x0016647c r14: 0x00000083 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535c0 r20: 0x000b32f2 r21: 0x001664a0 r22: 0x00000004 r23: 0x00000000 r24: 0x41148f74 r25: 0x00000001 r26: 0x66000000 r27: 0x41148f98 r28: 0x00000032 r29: 0x031e8dcc r30: 0x41148f70 r31: 0x4110891c ********** Date/Time: 2002-06-06 09:29:15 +0200 OS Version: 10.1.5 (Build 5S60) Host: localhost Command: python PID: 619 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x031a4dcc Thread 0 Crashed: #0 0x031a4dcc in 0x31a4dcc #1 0x41108ab4 in call_image_init_routines #2 0x41110318 in link_in_need_modules #3 0x41111bc4 in _dyld_link_module #4 0x70015b5c in NSLinkModule #5 0x004470dc in _PyImport_GetDynLoadFunc #6 0x0043c9c8 in _PyImport_LoadDynamicModule #7 0x0043a5e0 in load_module #8 0x0043c554 in imp_load_module #9 0x003f5fb0 in PyCFunction_Call #10 0x00423ef8 in eval_frame #11 0x004253d8 in PyEval_EvalCodeEx #12 0x004269c0 in fast_function #13 0x00423ffc in eval_frame #14 0x004253d8 in PyEval_EvalCodeEx #15 0x004269c0 in fast_function #16 0x00423ffc in eval_frame #17 0x004253d8 in PyEval_EvalCodeEx #18 0x004269c0 in fast_function #19 0x00423ffc in eval_frame #20 0x004253d8 in PyEval_EvalCodeEx #21 0x004269c0 in fast_function #22 0x00423ffc in eval_frame #23 0x004253d8 in PyEval_EvalCodeEx #24 0x004269c0 in fast_function #25 0x00423ffc in eval_frame #26 0x004253d8 in PyEval_EvalCodeEx #27 0x004269c0 in fast_function #28 0x00423ffc in eval_frame #29 0x004253d8 in PyEval_EvalCodeEx #30 0x003e83a0 in function_call #31 0x003d5d30 in PyObject_Call #32 0x003dd934 in instancemethod_call #33 0x003d5d30 in PyObject_Call #34 0x003dce3c in instance_call #35 0x003d5d30 in PyObject_Call #36 0x0042702c in ext_do_call #37 0x00424198 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x003e83a0 in function_call #40 0x003d5d30 in PyObject_Call #41 0x003dd934 in instancemethod_call #42 0x003d5d30 in PyObject_Call #43 0x003dce3c in instance_call #44 0x003d5d30 in PyObject_Call #45 0x00426dcc in do_call #46 0x00424014 in eval_frame #47 0x004253d8 in PyEval_EvalCodeEx #48 0x004205bc in PyEval_EvalCode #49 0x00443480 in run_node #50 0x004421ec in PyRun_InteractiveOneFlags #51 0x00441fb4 in PyRun_InteractiveLoopFlags #52 0x00441e54 in PyRun_AnyFileExFlags #53 0x0044c650 in Py_Main #54 0x00001e1c in _start #55 0x00001c4c in start PPC Thread State: srr0: 0x031a4dcc srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x41108ac0 ctr: 0x031a4dcc mq: 0x00000000 r0: 0x41108ab4 r1: 0xbfffdf10 r2: 0x00010410 r3: 0x41146060 r4: 0x00000000 r5: 0x00000000 r6: 0x00000000 r7: 0x030d1510 r8: 0x030d1724 r9: 0x411463a8 r10: 0x030d1000 r11: 0x00001ce8 r12: 0x031a4dcc r13: 0x001480ac r14: 0x00000083 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535c0 r20: 0x000b32f2 r21: 0x001480d0 r22: 0x00000004 r23: 0x00000000 r24: 0x41148f74 r25: 0x00000001 r26: 0x66000000 r27: 0x41148f98 r28: 0x00000032 r29: 0x031a4dcc r30: 0x41148f70 r31: 0x4110891c ********** --Apple-Mail-2--55536721 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Yo, I'm not sure wether I should post this directly to the list of enter a as bug somewhere. If it needs to be filed as a bug I'd gladly to it, if someone would be kind enough to point me to instructions on how to do it. I've just had a crash (segmentation fault) in machopython. I'm using version 2.2.1 compiled (on MOSX 10.1.4) from source and installed as a framework. I've upgraded to 10.1.5 but dunno if it's related. The crash is totally reproducible OMM. At the python prompt type: help() modules dbm It crashes while generating the list of dbm modules: --- cut help> modules dbm Here is a list of matching modules. Enter any module name to get more help. anydbm - Generic interface to all dbm clones. dbhash - Provide a (g)dbm-compatible interface to bsdhash.hashopen. dumbdbm - A dumb and slow but simple dbm clone. test.test_dbm - Test script for the dbm module test.test_dumbdbm - Test script for the dumbdbm module test.test_gdbm - Test script for the gdbm module dbm Segmentation fault --- cut I'm including the crash log below (the crash was triggered twice). HTH = tmk = --- cut Date/Time: 2002-06-06 09:24:01 +0200 OS Version: 10.1.5 (Build 5S60) Host: localhost Command: python PID: 614 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x031e8dcc Thread 0 Crashed: #0 0x031e8dcc in 0x31e8dcc #1 0x41108ab4 in call_image_init_routines #2 0x41110318 in link_in_need_modules #3 0x41111bc4 in _dyld_link_module #4 0x70015b5c in NSLinkModule #5 0x004470dc in _PyImport_GetDynLoadFunc #6 0x0043c9c8 in _PyImport_LoadDynamicModule #7 0x0043a5e0 in load_module #8 0x0043c554 in imp_load_module #9 0x003f5fb0 in PyCFunction_Call #10 0x00423ef8 in eval_frame #11 0x004253d8 in PyEval_EvalCodeEx #12 0x004269c0 in fast_function #13 0x00423ffc in eval_frame #14 0x004253d8 in PyEval_EvalCodeEx #15 0x004269c0 in fast_function #16 0x00423ffc in eval_frame #17 0x004253d8 in PyEval_EvalCodeEx #18 0x004269c0 in fast_function #19 0x00423ffc in eval_frame #20 0x004253d8 in PyEval_EvalCodeEx #21 0x004269c0 in fast_function #22 0x00423ffc in eval_frame #23 0x004253d8 in PyEval_EvalCodeEx #24 0x004269c0 in fast_function #25 0x00423ffc in eval_frame #26 0x004253d8 in PyEval_EvalCodeEx #27 0x004269c0 in fast_function #28 0x00423ffc in eval_frame #29 0x004253d8 in PyEval_EvalCodeEx #30 0x003e83a0 in function_call #31 0x003d5d30 in PyObject_Call #32 0x003dd934 in instancemethod_call #33 0x003d5d30 in PyObject_Call #34 0x003dce3c in instance_call #35 0x003d5d30 in PyObject_Call #36 0x0042702c in ext_do_call #37 0x00424198 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x003e83a0 in function_call #40 0x003d5d30 in PyObject_Call #41 0x003dd934 in instancemethod_call #42 0x003d5d30 in PyObject_Call #43 0x003dce3c in instance_call #44 0x003d5d30 in PyObject_Call #45 0x00426dcc in do_call #46 0x00424014 in eval_frame #47 0x004253d8 in PyEval_EvalCodeEx #48 0x004205bc in PyEval_EvalCode #49 0x00443480 in run_node #50 0x004421ec in PyRun_InteractiveOneFlags #51 0x00441fb4 in PyRun_InteractiveLoopFlags #52 0x00441e54 in PyRun_AnyFileExFlags #53 0x0044c650 in Py_Main #54 0x00001e1c in _start #55 0x00001c4c in start PPC Thread State: srr0: 0x031e8dcc srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x41108ac0 ctr: 0x031e8dcc mq: 0x00000000 r0: 0x41108ab4 r1: 0xbfffdf10 r2: 0x00010410 r3: 0x41146060 r4: 0x00000000 r5: 0x00000000 r6: 0x00000000 r7: 0x03115510 r8: 0x03115724 r9: 0x411463a8 r10: 0x03115000 r11: 0x00001ce8 r12: 0x031e8dcc r13: 0x0016647c r14: 0x00000083 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535c0 r20: 0x000b32f2 r21: 0x001664a0 r22: 0x00000004 r23: 0x00000000 r24: 0x41148f74 r25: 0x00000001 r26: 0x66000000 r27: 0x41148f98 r28: 0x00000032 r29: 0x031e8dcc r30: 0x41148f70 r31: 0x4110891c ********** Date/Time: 2002-06-06 09:29:15 +0200 OS Version: 10.1.5 (Build 5S60) Host: localhost Command: python PID: 619 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x031a4dcc Thread 0 Crashed: #0 0x031a4dcc in 0x31a4dcc #1 0x41108ab4 in call_image_init_routines #2 0x41110318 in link_in_need_modules #3 0x41111bc4 in _dyld_link_module #4 0x70015b5c in NSLinkModule #5 0x004470dc in _PyImport_GetDynLoadFunc #6 0x0043c9c8 in _PyImport_LoadDynamicModule #7 0x0043a5e0 in load_module #8 0x0043c554 in imp_load_module #9 0x003f5fb0 in PyCFunction_Call #10 0x00423ef8 in eval_frame #11 0x004253d8 in PyEval_EvalCodeEx #12 0x004269c0 in fast_function #13 0x00423ffc in eval_frame #14 0x004253d8 in PyEval_EvalCodeEx #15 0x004269c0 in fast_function #16 0x00423ffc in eval_frame #17 0x004253d8 in PyEval_EvalCodeEx #18 0x004269c0 in fast_function #19 0x00423ffc in eval_frame #20 0x004253d8 in PyEval_EvalCodeEx #21 0x004269c0 in fast_function #22 0x00423ffc in eval_frame #23 0x004253d8 in PyEval_EvalCodeEx #24 0x004269c0 in fast_function #25 0x00423ffc in eval_frame #26 0x004253d8 in PyEval_EvalCodeEx #27 0x004269c0 in fast_function #28 0x00423ffc in eval_frame #29 0x004253d8 in PyEval_EvalCodeEx #30 0x003e83a0 in function_call #31 0x003d5d30 in PyObject_Call #32 0x003dd934 in instancemethod_call #33 0x003d5d30 in PyObject_Call #34 0x003dce3c in instance_call #35 0x003d5d30 in PyObject_Call #36 0x0042702c in ext_do_call #37 0x00424198 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x003e83a0 in function_call #40 0x003d5d30 in PyObject_Call #41 0x003dd934 in instancemethod_call #42 0x003d5d30 in PyObject_Call #43 0x003dce3c in instance_call #44 0x003d5d30 in PyObject_Call #45 0x00426dcc in do_call #46 0x00424014 in eval_frame #47 0x004253d8 in PyEval_EvalCodeEx #48 0x004205bc in PyEval_EvalCode #49 0x00443480 in run_node #50 0x004421ec in PyRun_InteractiveOneFlags #51 0x00441fb4 in PyRun_InteractiveLoopFlags #52 0x00441e54 in PyRun_AnyFileExFlags #53 0x0044c650 in Py_Main #54 0x00001e1c in _start #55 0x00001c4c in start PPC Thread State: srr0: 0x031a4dcc srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x41108ac0 ctr: 0x031a4dcc mq: 0x00000000 r0: 0x41108ab4 r1: 0xbfffdf10 r2: 0x00010410 r3: 0x41146060 r4: 0x00000000 r5: 0x00000000 r6: 0x00000000 r7: 0x030d1510 r8: 0x030d1724 r9: 0x411463a8 r10: 0x030d1000 r11: 0x00001ce8 r12: 0x031a4dcc r13: 0x001480ac r14: 0x00000083 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535c0 r20: 0x000b32f2 r21: 0x001480d0 r22: 0x00000004 r23: 0x00000000 r24: 0x41148f74 r25: 0x00000001 r26: 0x66000000 r27: 0x41148f98 r28: 0x00000032 r29: 0x031a4dcc r30: 0x41148f70 r31: 0x4110891c ********** --Apple-Mail-2--55536721-- From bbug@speakeasy.org Thu Jun 6 21:46:16 2002 From: bbug@speakeasy.org (Bill Bug) Date: Thu, 6 Jun 2002 16:46:16 -0400 Subject: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure Message-ID: <726D1225-798E-11D6-A73A-0003931DC29E@speakeasy.org> Hi All, I've gotten stuck in my attempt to compile Python 2.2.1 from the source tarball on my 10.1.5 OS X machine that has the Apple Dev Suite installed with a functional gcc compiler. Any help/corrections y'all could provide would be greatly appreciated. Following the very clear README instructions on how to compile for Mac OS X, I built the Python core and most all the modules just fine using the recommended configure command: ./configure --enable-framework I was even able to get my installed build to pass most all the .py. All, that is, except for one module I know I need to use - and that the 'smart' compile test suite knows should be functional under Darwin & OS X. The module in question is pyexpat.o - the Python EXPAT-based XML Parser module. The SAX module is also not created, since it requires an XML parser, which it expects will be coming via pyexpat.o. I hunted through the Setup files in the /Modules directory and uncovered the line used by setup.py to create the compiler call designed to build this package. #EXPAT_DIR=/usr/local/src/expat #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat Unfortunately, my version of OS X does not contain that path, though it does contain EXPAT at /usr/local/expat. To make a long story a bit shorter, I downloaded the EXPAT source and compiled it, just to make certain I had all the components required by pyexpat.c. That placed the files the Python expat module requires - expat.h & libexpat.a - at /usr/local/include and /usr/local/lib, respectively. That installation tested just fine. I then added the following lines to my /Modules/Setup.local file: EXPAT_DIR=/usr/local/ pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat This info is used by the following code in setup.py to create the call to the gcc: expat_defs = [] expat_incs = find_file('expat.h', inc_dirs, []) if expat_incs is not None: # expat.h was found expat_defs = [('HAVE_EXPAT_H', 1)] else: expat_incs = find_file('xmlparse.h', inc_dirs, []) if (expat_incs is not None and self.compiler.find_library_file(lib_dirs, 'expat')): exts.append( Extension('pyexpat', ['pyexpat.c'], define_macros = expat_defs, libraries = ['expat']) ) The following lines in the 'find_file(filename, std_dirs, paths) function ultimately define whether the proper gcc call will get constructed: f = os.path.join(dir, filename) if os.path.exists(f): return [] Based on these lines, the call expat_incs = find_file('expat.h', inc_dirs, []) returns an empty array when it finds the 'expat.h' file at one of the include paths in 'inc_dirs'. Because of this, the line 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the 'HAVE_EXPAT_H' macro is not defined during compilation. This creates the following line in the makefile: cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -fno-common -dynamic -I. -I./Include -DHAVE_CONFIG_H -I/usr/local/include -c ./Modules/pyexpat.c -o Modules/pyexpat.o which leads to the following stderr msg during compilation: ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory make: *** [Modules/pyexpat.o] Error 1 Examining the pyexpat.c source file shows this line is nested amongst a set of pre-proc directives. I've listed these nested booleans below with the offending line marked with an arrow. #ifdef HAVE_EXPAT_H #include "expat.h" #ifdef XML_MAJOR_VERSION #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ + 0x100 * XML_MINOR_VERSION \ + XML_MICRO_VERSION) #else /* Assume the oldest Expat that used expat.h and did not have version info */ #define EXPAT_VERSION 0x015f00 #endif #else /* !defined(HAVE_EXPAT_H) */ ---> #include "xmlparse.h" /* Assume Expat 1.1 unless told otherwise */ #ifndef EXPAT_VERSION #define EXPAT_VERSION 0x010100 #endif #endif /* !defined(HAVE_EXPAT_H) */ A quick scan of the logic confirms what I believe I see in setup.py - the 'HAVE_EXPAT_H' macro is not getting defined, because 'find_file'() in setup.py DOES find 'expat.h' at one of the paths in the INCLUDED directories variable sent into setup.py. Have I misunderstood the compiler call in the makefile? Have I misunderstood what setup.py doing? I can't imagine why it would fail for this one module and work for all the others. Does that relate to the fact that the this is the only module being defined via Setup.local? Not surprisingly, the following lines then show up when running the installation tests, along with many other statements: ... test test_pyexpat skipped -- No module named pyexpat test test_sax skipped -- no XML parsers available ... 3 skips unexpected on darwin: test_sax test_locale test_pyexpat ... Once again, thanks very much for any assistance you can offer. Cheers, Bill Bug Senior Analyst Computer Vision Lab for Vertebrate Brain Mapping MCP/Hahnemann University Philadelphia, PA, USA 19129 From just@letterror.com Thu Jun 6 21:51:09 2002 From: just@letterror.com (Just van Rossum) Date: Thu, 6 Jun 2002 22:51:09 +0200 Subject: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure In-Reply-To: <726D1225-798E-11D6-A73A-0003931DC29E@speakeasy.org> Message-ID: Bill Bug wrote: > Once again, thanks very much for any assistance you can offer. I can't help you with any of the details you mention, but I managed to get a working pyexpat by installing the latest PyXML package (pyxml.sf.net). That is not to say it shouldn't have been built out of the box, merely a way to get going... Just From curtisg@curtisg.net Sat Jun 8 00:05:25 2002 From: curtisg@curtisg.net (Curtis Galloway) Date: Fri, 7 Jun 2002 16:05:25 -0700 Subject: [Pythonmac-SIG] MacPython vs. Python Message-ID: <0D4C7B00-7A6B-11D6-855D-003065FBF976@curtisg.net> Hi all. I am a longtime Python user on various flavors of UNIX but am relatively new to the Mac world. My only experience has been with OS X, so I am somewhat ignorant about the OS 9 world. I'm interested in wrapping OS X frameworks like CoreFoundation so I can use them from Python. I see that MacPython has wrapped versions, and I also saw something somewhere that said people are working on merging MacPython into the rest of Python. Who's working on that? What's the status? Can I help? I apologize if this is a frequently asked question. --Curtis From jmillr@umich.edu Sat Jun 8 17:25:35 2002 From: jmillr@umich.edu (John Miller) Date: Sat, 8 Jun 2002 12:25:35 -0400 Subject: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure In-Reply-To: <20020607160002.27211.31741.Mailman@mail.python.org> Message-ID: <5C626B97-7AFC-11D6-B895-00039303967A@umich.edu> I first want to thank Bill for submitting this detailed information, and second, I want to confirm that exactly the same happened with me on both my desktop and laptop MacOS X machines (except that I didn't '--enable-framework'). If anyone can tell us how to fix this, I'd be very appreciative. I'm glad that Just told us the workaround, but I'm more interested in having the installation process work 'out of the box', if possible. John Miller On Friday, June 7, 2002, at 12:00 PM, Bill Bug wrote: > > Hi All, > > I've gotten stuck in my attempt to compile Python 2.2.1 from the source > tarball on my 10.1.5 OS X machine that has the Apple Dev Suite installed > with a functional gcc compiler. > > Any help/corrections y'all could provide would be greatly appreciated. > > Following the very clear README instructions on how to compile for Mac > OS X, I built the Python core and most all the modules just fine using > the recommended configure command: > > ./configure --enable-framework > > I was even able to get my installed build to pass most all the > .py. > > All, that is, except for one module I know I need to use - and that the > 'smart' compile test suite knows should be functional under Darwin & OS > X. The module in question is pyexpat.o - the Python EXPAT-based XML > Parser module. The SAX module is also not created, since it requires an > XML parser, which it expects will be coming via pyexpat.o. > > I hunted through the Setup files in the /Modules directory and uncovered > the line used by setup.py to create the compiler call designed to build > this package. > > #EXPAT_DIR=/usr/local/src/expat > #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat > > Unfortunately, my version of OS X does not contain that path, though it > does contain EXPAT at /usr/local/expat. > > To make a long story a bit shorter, I downloaded the EXPAT source and > compiled it, just to make certain I had all the components required by > pyexpat.c. That placed the files the Python expat module requires - > expat.h & libexpat.a - at /usr/local/include and /usr/local/lib, > respectively. That installation tested just fine. > > I then added the following lines to my /Modules/Setup.local > file: > EXPAT_DIR=/usr/local/ > pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat > > This info is used by the following code in setup.py to create the call > to the gcc: > > expat_defs = [] > expat_incs = find_file('expat.h', inc_dirs, []) > if expat_incs is not None: > # expat.h was found > expat_defs = [('HAVE_EXPAT_H', 1)] > else: > expat_incs = find_file('xmlparse.h', inc_dirs, []) > > if (expat_incs is not None and > self.compiler.find_library_file(lib_dirs, 'expat')): > exts.append( Extension('pyexpat', ['pyexpat.c'], > define_macros = expat_defs, > libraries = ['expat']) ) > > The following lines in the 'find_file(filename, std_dirs, paths) > function ultimately define whether the proper gcc call will get > constructed: > > f = os.path.join(dir, filename) > if os.path.exists(f): return [] > > Based on these lines, the call expat_incs = find_file('expat.h', > inc_dirs, []) returns an empty array when it finds the 'expat.h' file at > one of the include paths in 'inc_dirs'. Because of this, the line > 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the 'HAVE_EXPAT_H' > macro is not defined during compilation. > > This creates the following line in the makefile: > cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -fno-common > -dynamic -I. -I./Include -DHAVE_CONFIG_H -I/usr/local/include -c > ./Modules/pyexpat.c -o Modules/pyexpat.o > > which leads to the following stderr msg during compilation: > ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory > make: *** [Modules/pyexpat.o] Error 1 > > Examining the pyexpat.c source file shows this line is nested amongst a > set of pre-proc directives. I've listed these nested booleans below > with the offending line marked with an arrow. > > #ifdef HAVE_EXPAT_H > #include "expat.h" > #ifdef XML_MAJOR_VERSION > #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ > + 0x100 * XML_MINOR_VERSION \ > + XML_MICRO_VERSION) > #else > /* Assume the oldest Expat that used expat.h and did not > have version info */ > #define EXPAT_VERSION 0x015f00 > #endif > #else /* !defined(HAVE_EXPAT_H) */ > ---> #include "xmlparse.h" > /* Assume Expat 1.1 unless told otherwise */ > #ifndef EXPAT_VERSION > #define EXPAT_VERSION 0x010100 > #endif > #endif /* !defined(HAVE_EXPAT_H) */ > > A quick scan of the logic confirms what I believe I see in setup.py - > the 'HAVE_EXPAT_H' macro is not getting defined, because 'find_file'() > in setup.py DOES find 'expat.h' at one of the paths in the INCLUDED > directories variable sent into setup.py. > > Have I misunderstood the compiler call in the makefile? Have I > misunderstood what setup.py doing? I can't imagine why it would fail > for this one module and work for all the others. Does that relate to > the fact that the this is the only module being defined via Setup.local? > > Not surprisingly, the following lines then show up when running the > installation tests, along with many other statements: > ... > test test_pyexpat skipped -- No module named pyexpat > test test_sax skipped -- no XML parsers available > ... > 3 skips unexpected on darwin: > test_sax test_locale test_pyexpat > ... > > Once again, thanks very much for any assistance you can offer. > > Cheers, > Bill Bug > Senior Analyst > Computer Vision Lab for Vertebrate Brain Mapping > MCP/Hahnemann University > Philadelphia, PA, USA 19129 From Jack.Jansen@oratrix.com Sun Jun 9 00:22:02 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 9 Jun 2002 01:22:02 +0200 Subject: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure In-Reply-To: <5C626B97-7AFC-11D6-B895-00039303967A@umich.edu> Message-ID: <89A9B4D7-7B36-11D6-ACAA-003065517236@oratrix.com> Expat configuration was a mess up until (and including) Python 2.2.1. For this reason the relevant expat source files will be included in Python 2.3. For Python 2.2.X you have to get expat yourself, but even then it doesn't always work out of the box, as Bill found out. The easiest solution is probably to hack up setup.py to make it do the right thing. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dan@gui.com Sun Jun 9 22:20:05 2002 From: dan@gui.com (Dan Shafer) Date: Sun, 09 Jun 2002 14:20:05 -0700 Subject: [Pythonmac-SIG] Does CVS Require dev Tools? Message-ID: I am attempting a completely virgin install of PythonCard on my G3 laptop under OS X. I got machopython and wxpython-mac to install and run just fine. I wanted to get the cvs on PythonCard, so I went into terminal and typed which cvs to be sure I had it. I do. It's at /usr/bin/cvs Cool. So I go into my python code working directory (called pycode), and type the code from the pythoncard cvs site that is supposed to set up anonymous access. I just copy and paste it, so I'm sure the syntax is right. I've done this a few times. I get the following error in terminal: cvs can't open library: /usr/lib/:libgssapi_krb5.2.2.dylib (No such file or directory, errno = 2) My working hypothesis is that I need to install Dev Tools on this box to get CVS to work correctly. is that the case? If not, what am I missing or doing wrong here? Just for completeness, the code to activate cvs I'm running, taken from the site, is: cvs -d:pserver:anonymous@cvs.pythoncard.sourceforge.net:/cvsroot/pythoncard login Thanks for the help. -- Dan Shafer, Product Development Expert Helping you turn your best ideas into products that sell http://www.danshafer.com From lists@netelligent.biz Sun Jun 9 22:29:24 2002 From: lists@netelligent.biz (lists) Date: Sun, 9 Jun 2002 23:29:24 +0200 Subject: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure In-Reply-To: <726D1225-798E-11D6-A73A-0003931DC29E@speakeasy.org> Message-ID: Yo, I can't help with the details you outlined below (I'm too tired to read through %-). I've successfully build python as a framework with expat just a couple of days ago. I first tried to follow the instructions in setup.py but I found them somehow misleading: 1. The expat source they're pointing to seems quite old 2. I could never found the EXPAT_DIR refered to in this excerpt from setup.py --- cut # EXPAT_DIR, below, should point to the expat/ directory created by # unpacking the Expat source distribution. --- cut So instead I did a search on google and found the following helpful page which pointed to another more recent version of the expat source , I downloaded and expanded the archive and went for the ./configure, make, sudo make install routine. Then I rebuilt python from source and just checked that the pyexpat module was built by trying to import it which worked! HTH. = tmk = On Thursday, June 6, 2002, at 10:46 , Bill Bug wrote: > Hi All, > > I've gotten stuck in my attempt to compile Python 2.2.1 from the > source tarball on my 10.1.5 OS X machine that has the Apple Dev > Suite installed with a functional gcc compiler. > > Any help/corrections y'all could provide would be greatly appreciated. > > Following the very clear README instructions on how to compile for > Mac OS X, I built the Python core and most all the modules just > fine using the recommended configure command: > > ./configure --enable-framework > > I was even able to get my installed build to pass most all the > .py. > > All, that is, except for one module I know I need to use - and > that the 'smart' compile test suite knows should be functional > under Darwin & OS X. The module in question is pyexpat.o - the > Python EXPAT-based XML Parser module. The SAX module is also not > created, since it requires an XML parser, which it expects will be > coming via pyexpat.o. > > I hunted through the Setup files in the /Modules directory and > uncovered the line used by setup.py to create the compiler call > designed to build this package. > > #EXPAT_DIR=/usr/local/src/expat > #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat > > Unfortunately, my version of OS X does not contain that path, > though it does contain EXPAT at /usr/local/expat. > > To make a long story a bit shorter, I downloaded the EXPAT source > and compiled it, just to make certain I had all the components > required by pyexpat.c. That placed the files the Python expat > module requires - expat.h & libexpat.a - at /usr/local/include and > /usr/local/lib, respectively. That installation tested just fine. > > I then added the following lines to my > /Modules/Setup.local file: > EXPAT_DIR=/usr/local/ > pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat > > This info is used by the following code in setup.py to create the > call to the gcc: > > expat_defs = [] > expat_incs = find_file('expat.h', inc_dirs, []) > if expat_incs is not None: > # expat.h was found > expat_defs = [('HAVE_EXPAT_H', 1)] > else: > expat_incs = find_file('xmlparse.h', inc_dirs, []) > > if (expat_incs is not None and > self.compiler.find_library_file(lib_dirs, 'expat')): > exts.append( Extension('pyexpat', ['pyexpat.c'], > define_macros = expat_defs, > libraries = ['expat']) ) > > The following lines in the 'find_file(filename, std_dirs, paths) > function ultimately define whether the proper gcc call will get > constructed: > > f = os.path.join(dir, filename) > if os.path.exists(f): return [] > > Based on these lines, the call expat_incs = find_file('expat.h', > inc_dirs, []) returns an empty array when it finds the 'expat.h' > file at one of the include paths in 'inc_dirs'. Because of this, > the line 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the > 'HAVE_EXPAT_H' macro is not defined during compilation. > > This creates the following line in the makefile: > cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -fno-common -dynamic -I. -I./Include -DHAVE_CONFIG_H > -I/usr/local/include -c ./Modules/pyexpat.c -o Modules/pyexpat.o > > which leads to the following stderr msg during compilation: > ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory > make: *** [Modules/pyexpat.o] Error 1 > > Examining the pyexpat.c source file shows this line is nested > amongst a set of pre-proc directives. I've listed these nested > booleans below with the offending line marked with an arrow. > > #ifdef HAVE_EXPAT_H > #include "expat.h" > #ifdef XML_MAJOR_VERSION > #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ > + 0x100 * XML_MINOR_VERSION \ > + XML_MICRO_VERSION) > #else > /* Assume the oldest Expat that used expat.h and did > not have version info */ > #define EXPAT_VERSION 0x015f00 > #endif > #else /* !defined(HAVE_EXPAT_H) */ > ---> #include "xmlparse.h" > /* Assume Expat 1.1 unless told otherwise */ > #ifndef EXPAT_VERSION > #define EXPAT_VERSION 0x010100 > #endif > #endif /* !defined(HAVE_EXPAT_H) */ > > A quick scan of the logic confirms what I believe I see in > setup.py - the 'HAVE_EXPAT_H' macro is not getting defined, > because 'find_file'() in setup.py DOES find 'expat.h' at one of > the paths in the INCLUDED directories variable sent into setup.py. > > Have I misunderstood the compiler call in the makefile? Have I > misunderstood what setup.py doing? I can't imagine why it would > fail for this one module and work for all the others. Does that > relate to the fact that the this is the only module being defined > via Setup.local? > > Not surprisingly, the following lines then show up when running > the installation tests, along with many other statements: > ... > test test_pyexpat skipped -- No module named pyexpat > test test_sax skipped -- no XML parsers available > ... > 3 skips unexpected on darwin: > test_sax test_locale test_pyexpat > ... > > Once again, thanks very much for any assistance you can offer. > > Cheers, > Bill Bug > Senior Analyst > Computer Vision Lab for Vertebrate Brain Mapping > MCP/Hahnemann University > Philadelphia, PA, USA 19129 > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lists@netelligent.biz Sun Jun 9 22:37:31 2002 From: lists@netelligent.biz (lists) Date: Sun, 9 Jun 2002 23:37:31 +0200 Subject: [Pythonmac-SIG] Does CVS Require dev Tools? In-Reply-To: Message-ID: <1A957F26-7BF1-11D6-975B-003065C18BA0@netelligent.biz> Yo, On Sunday, June 9, 2002, at 11:20 , Dan Shafer wrote: > I am attempting a completely virgin install of PythonCard on my G3 > laptop under OS X. > > I got machopython and wxpython-mac to install and run just fine. I > wanted to get the cvs on PythonCard, so I went into terminal and > typed > > which cvs > > to be sure I had it. I do. It's at /usr/bin/cvs > > Cool. > > So I go into my python code working directory (called pycode), and > type the code from the pythoncard cvs site that is supposed to set > up anonymous access. I just copy and paste it, so I'm sure the > syntax is right. I've done this a few times. > > I get the following error in terminal: > > cvs can't open library: /usr/lib/:libgssapi_krb5.2.2.dylib (No > such file or directory, errno = 2) I've tried login to the cvs server you point to below and it's working without problem OMM. I do have de Dev Tools installed. I checked in my /usr/lib for the libgssapi_krb5.2.2.dylib and indeed it's there. You may want to check if that library exists in the /usr/lib directory of your G3 laptop. I have no idea whether this library is installed by the Dev Tools though. HTH = tmk = > > My working hypothesis is that I need to install Dev Tools on this > box to get CVS to work correctly. > > is that the case? If not, what am I missing or doing wrong here? > > Just for completeness, the code to activate cvs I'm running, taken > from the site, is: > > cvs > -d:pserver:anonymous@cvs.pythoncard.sourceforge.net:/cvsroot/pythoncard > login > > Thanks for the help. > -- Dan Shafer, Product Development Expert > Helping you turn your best ideas into products that sell > http://www.danshafer.com > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen@oratrix.com Sun Jun 9 22:13:17 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 9 Jun 2002 23:13:17 +0200 Subject: [Pythonmac-SIG] Update feature of BuildApplet - does anyone use it? Message-ID: Does anyone use the update feature of BuildApplet? This is the feature that you can drop an existing applet (of a previous version of Python, for instance) on BuildApplet, and it will convert it to the current version of Python. I'm asking because (a) I suspect that it doesn't work, and hasn't worked for a long time and (b) it complicates the code, so I want to get rid of it. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dan@gui.com Mon Jun 10 07:56:58 2002 From: dan@gui.com (Dan Shafer) Date: Sun, 09 Jun 2002 23:56:58 -0700 Subject: [Pythonmac-SIG] Does CVS Require dev Tools? In-Reply-To: <1A957F26-7BF1-11D6-975B-003065C18BA0@netelligent.biz> References: <1A957F26-7BF1-11D6-975B-003065C18BA0@netelligent.biz> Message-ID: At 11:37 PM +0200 6/9/02, lists wrote: >Yo, > > >I've tried login to the cvs server you point to below and it's >working without problem OMM. I do have de Dev Tools installed. >I checked in my /usr/lib for the libgssapi_krb5.2.2.dylib and indeed >it's there. >You may want to check if that library exists in the /usr/lib >directory of your G3 laptop. It does not. >I have no idea whether this library is installed by the Dev Tools though. Tomorrow, I will find out! >HTH > >= tmk = > >> >>My working hypothesis is that I need to install Dev Tools on this >>box to get CVS to work correctly. >> >>is that the case? If not, what am I missing or doing wrong here? >> >>Just for completeness, the code to activate cvs I'm running, taken >>from the site, is: >> >>cvs >>-d:pserver:anonymous@cvs.pythoncard.sourceforge.net:/cvsroot/pythoncard >>login >> >>Thanks for the help. >>-- Dan Shafer, Product Development Expert >>Helping you turn your best ideas into products that sell >>http://www.danshafer.com >> >> >>_______________________________________________ >>Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>http://mail.python.org/mailman/listinfo/pythonmac-sig -- Dan Shafer, Product Development Expert Helping you turn your best ideas into products that sell http://www.danshafer.com From just@letterror.com Mon Jun 10 08:59:58 2002 From: just@letterror.com (Just van Rossum) Date: Mon, 10 Jun 2002 09:59:58 +0200 Subject: [Pythonmac-SIG] Update feature of BuildApplet - does anyone use it? In-Reply-To: Message-ID: Jack Jansen wrote: > Does anyone use the update feature of BuildApplet? This is the > feature that you can drop an existing applet (of a previous > version of Python, for instance) on BuildApplet, and it will > convert it to the current version of Python. > > I'm asking because (a) I suspect that it doesn't work, and > hasn't worked for a long time and (b) it complicates the code, > so I want to get rid of it. +1: I've _never_ used it... Just From lists@netelligent.biz Mon Jun 10 10:21:39 2002 From: lists@netelligent.biz (lists) Date: Mon, 10 Jun 2002 11:21:39 +0200 Subject: [Pythonmac-SIG] Update feature of BuildApplet - does anyone use it? In-Reply-To: Message-ID: <782BEBA7-7C53-11D6-975B-003065C18BA0@netelligent.biz> On Sunday, June 9, 2002, at 11:13 , Jack Jansen wrote: > Does anyone use the update feature of BuildApplet? This is the > feature that you can drop an existing applet (of a previous > version of Python, for instance) on BuildApplet, and it will > convert it to the current version of Python. > > I'm asking because (a) I suspect that it doesn't work, and hasn't > worked for a long time and (b) it complicates the code, so I want > to get rid of it. It's been a year or so since I've used the buildApplet (since I've switched to machopython?) and even back then when I used it a lot to "compile" CGIs I never used the update feature. In fact I'd confess that I did not even know it exists :-). If I knew it existed I would have used it quite a lot. But since I manage to do without you can get rid of it AFAIC. = tmk = From pecora@anvil.nrl.navy.mil Mon Jun 10 12:25:43 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Mon, 10 Jun 2002 07:25:43 -0400 Subject: [Pythonmac-SIG] Update feature of BuildApplet - does anyone use it? In-Reply-To: References: Message-ID: >Jack Jansen wrote: > >> Does anyone use the update feature of BuildApplet? This is the >> feature that you can drop an existing applet (of a previous >> version of Python, for instance) on BuildApplet, and it will >> convert it to the current version of Python. >> >> I'm asking because (a) I suspect that it doesn't work, and >> hasn't worked for a long time and (b) it complicates the code, >> so I want to get rid of it. Didn't even know it existed so I would not miss it. -- Cheers, Lou Pecora From gherman@darwin.in-berlin.de Mon Jun 10 12:56:35 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 10 Jun 2002 13:56:35 +0200 (CEST) Subject: [Pythonmac-SIG] Python and Jaguar Message-ID: <1023710195.3d0493f349f89@webmail.in-berlin.de> Hi, I heard that Jaguar (OS X 10.2) finally comes with Python 2.2 bundled, but I don't have any developer prerelease of it, so I can only guess it's a Unix compile of 2.2.1. Has anybody already been riding on it to give more details? Dinu From owen@astro.washington.edu Mon Jun 10 17:12:21 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 10 Jun 2002 09:12:21 -0700 Subject: [Pythonmac-SIG] Re: Update feature of BuildApplet - does anyone use it? Message-ID: >Does anyone use the update feature of BuildApplet? This is the >feature that you can drop an existing applet (of a previous version >of Python, for instance) on BuildApplet, and it will convert it to >the current version of Python. I never even knew this feature existed. I'm happy to update my applets by dragging the source (though I wish the source could optionally be included with the applet, so everything was in one place and I didn't risk losing the source or guessing wrong which source file went with which version of the applet). -- Russell From Chris.Barker@noaa.gov Mon Jun 10 17:35:22 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Mon, 10 Jun 2002 09:35:22 -0700 Subject: [Pythonmac-SIG] Update feature of BuildApplet - does anyoneuse it? References: Message-ID: <3D04D4A0.3A641550@noaa.gov> "Louis M. Pecora" wrote: > >Jack Jansen wrote: > >> Does anyone use the update feature of BuildApplet? This is the > Didn't even know it existed so I would not miss it. Neither did I, so ditto. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From dev@brotsky.com Mon Jun 10 17:58:56 2002 From: dev@brotsky.com (Daniel Brotsky) Date: Mon, 10 Jun 2002 09:58:56 -0700 Subject: [Pythonmac-SIG] Update feature of BuildApplet - does anyoneuse it? In-Reply-To: <3D04D4A0.3A641550@noaa.gov> Message-ID: <59E49C78-7C93-11D6-9B3F-0003931036B4@brotsky.com> On Monday, June 10, 2002, at 09:35 AM, Chris Barker wrote: > "Louis M. Pecora" wrote: >>> Jack Jansen wrote: >>>> Does anyone use the update feature of BuildApplet? This is the > >> Didn't even know it existed so I would not miss it. > > Neither did I, so ditto. Ditto that ditto. dan From William.Bug@drexel.edu Mon Jun 10 20:54:20 2002 From: William.Bug@drexel.edu (Bill Bug) Date: Mon, 10 Jun 2002 15:54:20 -0400 Subject: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure In-Reply-To: <88A60DF3-7B2F-11D6-B653-0005029E8B13@pacbell.net> Message-ID: Many thanks to Bill F. & Jack for the helpful suggestions. Following Bill's instructions to the letter did the trick. I'd also add the reminder to follow the Python README instructions to the letter. In particular, if you fail to obey the advice below, you will not get through the regression tests: "Mac OS X 10: One of the regular expression tests fails with a SEGV due to the small stack size used by default, if you do "limit stacksize 2048" before "make test" it should work." With that pre-requisite, I know get the following result from running the regression tests: "168 tests OK. 19 tests skipped: test_al test_cd test_cl test_curses test_dl test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_nis test_ntpath test_poll test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 1 skip unexpected on darwin: test_locale" Now, the only module the python configure/setup.py process can't pick-up automagically is the one required to run the localization tests. This is something I believe I can live without, though I'll find out for certain after testing my connection to Apache, MySQL and postgreSQL. I may also end up needing some of the other modules that are not typically loaded in a Darwin install - e.g., socket_ssl, unicode_file, imgfile, etc. I assume this can be done *relatively* easily by placing the proper lines in the Modules/Setup.local file prior to running 'configure'. It sounds like expat will be included as a part of the Python 2.3 source tree, which will definitely make this process go a little easier. Thanks again for the help. Cheers, Bill On Saturday, June 8, 2002, at 06:31 PM, bill fancher wrote: > If you've got the support files, everything Just Works (tm). Here's the > complete drill for installing 2.2.1 with readline (can't live without > this) > and pyexpat: > > #download and install readline > curl -O ftp://ftp.gnu.org/gnu/readline/readline-4.2a.tar.gz > gnutar xzf readline*.gz > cd readline-4.2a > ./configure > make > make install > cd .. > #download and install expat > curl -O > http://telia.dl.sourceforge.net/sourceforge/expat/expat-1.95.3.tar. > gz > tar xzf expat-1.95.3.tar.gz > cd expat-1.95.3 > ./configure > make > make install > cd .. > #download and install python > curl -O ftp://ftp.python.org/pub/python/2.2.1/Python-2.2.1.tgz > tar xzf Python-2.2.1.tgz > cd Python-2.2.1 > # The following line prevents some warnings (maybe) and turns off debug > symbols > # which makes the installation much smaller (~25MB as opposed to ~65MB). > setenv OPT '-no-cpp-precomp -O3' > ./configure > make > make install > cd .. > > To build as a framework, change the last four lines to: > > ./configure --enable-framework > make > make frameworkinstall > cd .. > > HTH, > > -- > bill > > On Saturday, June 8, 2002, at 09:25 AM, John Miller wrote: > >> I first want to thank Bill for submitting this detailed information, >> and second, I want to confirm that exactly the same happened with me >> on both my desktop and laptop MacOS X machines (except that I didn't >> '--enable-framework'). If anyone can tell us how to fix this, I'd be >> very appreciative. I'm glad that Just told us the workaround, but I'm >> more interested in having the installation process work 'out of the >> box', if possible. >> >> John Miller >> >> >> On Friday, June 7, 2002, at 12:00 PM, Bill Bug >> wrote: >> >>> >>> Hi All, >>> >>> I've gotten stuck in my attempt to compile Python 2.2.1 from the >>> source >>> tarball on my 10.1.5 OS X machine that has the Apple Dev Suite >>> installed >>> with a functional gcc compiler. >>> >>> Any help/corrections y'all could provide would be greatly appreciated. >>> >>> Following the very clear README instructions on how to compile for Mac >>> OS X, I built the Python core and most all the modules just fine using >>> the recommended configure command: >>> >>> ./configure --enable-framework >>> >>> I was even able to get my installed build to pass most all the >>> .py. >>> >>> All, that is, except for one module I know I need to use - and that >>> the >>> 'smart' compile test suite knows should be functional under Darwin & >>> OS >>> X. The module in question is pyexpat.o - the Python EXPAT-based XML >>> Parser module. The SAX module is also not created, since it requires >>> an >>> XML parser, which it expects will be coming via pyexpat.o. >>> >>> I hunted through the Setup files in the /Modules directory and >>> uncovered >>> the line used by setup.py to create the compiler call designed to >>> build >>> this package. >>> >>> #EXPAT_DIR=/usr/local/src/expat >>> #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat >>> >>> Unfortunately, my version of OS X does not contain that path, though >>> it >>> does contain EXPAT at /usr/local/expat. >>> >>> To make a long story a bit shorter, I downloaded the EXPAT source and >>> compiled it, just to make certain I had all the components required by >>> pyexpat.c. That placed the files the Python expat module requires - >>> expat.h & libexpat.a - at /usr/local/include and /usr/local/lib, >>> respectively. That installation tested just fine. >>> >>> I then added the following lines to my >>> /Modules/Setup.local >>> file: >>> EXPAT_DIR=/usr/local/ >>> pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat >>> >>> This info is used by the following code in setup.py to create the call >>> to the gcc: >>> >>> expat_defs = [] >>> expat_incs = find_file('expat.h', inc_dirs, []) >>> if expat_incs is not None: >>> # expat.h was found >>> expat_defs = [('HAVE_EXPAT_H', 1)] >>> else: >>> expat_incs = find_file('xmlparse.h', inc_dirs, []) >>> >>> if (expat_incs is not None and >>> self.compiler.find_library_file(lib_dirs, 'expat')): >>> exts.append( Extension('pyexpat', ['pyexpat.c'], >>> define_macros = expat_defs, >>> libraries = ['expat']) ) >>> >>> The following lines in the 'find_file(filename, std_dirs, paths) >>> function ultimately define whether the proper gcc call will get >>> constructed: >>> >>> f = os.path.join(dir, filename) >>> if os.path.exists(f): return [] >>> >>> Based on these lines, the call expat_incs = find_file('expat.h', >>> inc_dirs, []) returns an empty array when it finds the 'expat.h' file >>> at >>> one of the include paths in 'inc_dirs'. Because of this, the line >>> 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the >>> 'HAVE_EXPAT_H' >>> macro is not defined during compilation. >>> >>> This creates the following line in the makefile: >>> cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -fno-common >>> -dynamic -I. -I./Include -DHAVE_CONFIG_H -I/usr/local/include -c >>> ./Modules/pyexpat.c -o Modules/pyexpat.o >>> >>> which leads to the following stderr msg during compilation: >>> ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory >>> make: *** [Modules/pyexpat.o] Error 1 >>> >>> Examining the pyexpat.c source file shows this line is nested >>> amongst a >>> set of pre-proc directives. I've listed these nested booleans below >>> with the offending line marked with an arrow. >>> >>> #ifdef HAVE_EXPAT_H >>> #include "expat.h" >>> #ifdef XML_MAJOR_VERSION >>> #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ >>> + 0x100 * XML_MINOR_VERSION \ >>> + XML_MICRO_VERSION) >>> #else >>> /* Assume the oldest Expat that used expat.h and did not >>> have version info */ >>> #define EXPAT_VERSION 0x015f00 >>> #endif >>> #else /* !defined(HAVE_EXPAT_H) */ >>> ---> #include "xmlparse.h" >>> /* Assume Expat 1.1 unless told otherwise */ >>> #ifndef EXPAT_VERSION >>> #define EXPAT_VERSION 0x010100 >>> #endif >>> #endif /* !defined(HAVE_EXPAT_H) */ >>> >>> A quick scan of the logic confirms what I believe I see in setup.py - >>> the 'HAVE_EXPAT_H' macro is not getting defined, because 'find_file'() >>> in setup.py DOES find 'expat.h' at one of the paths in the INCLUDED >>> directories variable sent into setup.py. >>> >>> Have I misunderstood the compiler call in the makefile? Have I >>> misunderstood what setup.py doing? I can't imagine why it would fail >>> for this one module and work for all the others. Does that relate to >>> the fact that the this is the only module being defined via >>> Setup.local? >>> >>> Not surprisingly, the following lines then show up when running the >>> installation tests, along with many other statements: >>> ... >>> test test_pyexpat skipped -- No module named pyexpat >>> test test_sax skipped -- no XML parsers available >>> ... >>> 3 skips unexpected on darwin: >>> test_sax test_locale test_pyexpat >>> ... >>> >>> Once again, thanks very much for any assistance you can offer. >>> >>> Cheers, >>> Bill Bug >>> Senior Analyst >>> Computer Vision Lab for Vertebrate Brain Mapping >>> MCP/Hahnemann University >>> Philadelphia, PA, USA 19129 >> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > Bill Bug Senior Analyst/Ontological Engineer Computer Vision Laboratory for Vertebrate Brain Mapping (CVLVBM) MCP/Hahnemann University 2900 Queen Lane Philadelphia, PA 19129 William.Bug@drexel.edu From Jack.Jansen@cwi.nl Tue Jun 11 10:35:35 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 11 Jun 2002 11:35:35 +0200 Subject: [Pythonmac-SIG] Re: Update feature of BuildApplet - does anyone use it? In-Reply-To: Message-ID: <94EF939C-7D1E-11D6-9D2C-0030655234CE@cwi.nl> On Monday, June 10, 2002, at 06:12 , Russell E Owen wrote: > I wish the source could optionally be included with the applet, so > everything was in one place and I didn't risk losing the source or > guessing wrong which source file went with which version of the applet). I guess we could optionally put the source in a resource (a TEXT resource named "__main__.py" springs to mind for MacPython), and we could probably teach the IDE to understand such files. There would be a bit more magic involved, i.e. when saving such a file the IDE should really do the equivalent of BuildApplet. I can easily do the BuildApplet support (which would be an optional argument buildtools.process), anyone willing to tackle the IDE bits and pieces? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From waw@well.com Tue Jun 11 17:39:03 2002 From: waw@well.com (Andy Wright) Date: Tue, 11 Jun 2002 12:39:03 -0400 Subject: [Pythonmac-SIG] Re: Anonymous CVS downloads on OS X In-Reply-To: <20020610160003.3693.42759.Mailman@mail.python.org> Message-ID: On Monday, June 10, 2002, at 12:00 PM, Dan Shafer wrote: > I am attempting a completely virgin install of PythonCard on my G3 > laptop under OS X. > > I got machopython and wxpython-mac to install and run just fine. I > wanted to get the cvs on PythonCard, so I ... > ... go into my python code working directory (called pycode), and > type the code from the pythoncard cvs site that is supposed to set up > anonymous access. I just copy and paste it, so I'm sure the syntax is > right. I've done this a few times. > > I get the following error in terminal: > > cvs can't open library: /usr/lib/:libgssapi_krb5.2.2.dylib (No such > file or directory, errno = 2) > > My working hypothesis is that I need to install Dev Tools on this box > to get CVS to work correctly. Dan -- I followed the same procedure you reported above a week ago to get PythonCard 0.6.7 source and got some non-network error as you did. I have the developer tools installed. I also have a copy of the freeware GUI CVS program wrapper AnonymousGet . So I used it, following as a prototype one of its preset sourceForge bookmarks. No problems. Possibly the problem is compatibility of the pythoncard cvs site's recommended anonymous CVS options? BTW, big thanks for your efforts in pythonCard documentation, it counts. -- Andy Wright From stephenm@humongous.com Tue Jun 11 19:38:44 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Tue, 11 Jun 2002 11:38:44 -0700 Subject: [Pythonmac-SIG] proper include for bundled h files Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE77D@sea-horse.humongous.com> I am having problems getting the h file recognized from my CW compiles, using a bundled Python. Here are the steps I have done. 1. Downloaded the Python-2.2.1.tgz from python.org 2. Followed the directions in Mac/OSX folder to build bundled version of Python in the default location /Library/Frameworks. 3. Use CodeWarrior stationary to build a C++ Toolbox Mach-O project. 4. Add the python.framework to the newly created project. 5. add a #include line to the MyFramework.cp file. 6. Try to compile. Get a, "The file "python.h" cannot be opened." error. I have also tried variations such as , , not requiring framework style includes. nothing seems to work. Someone see what I am doing wrong? From dan@danshafer.com Tue Jun 11 20:23:33 2002 From: dan@danshafer.com (Dan Shafer) Date: Tue, 11 Jun 2002 12:23:33 -0700 Subject: [Pythonmac-SIG] Re: Anonymous CVS downloads on OS X In-Reply-To: References: Message-ID: At 12:39 PM -0400 6/11/02, Andy Wright wrote: >On Monday, June 10, 2002, at 12:00 PM, Dan Shafer wrote: > >>I am attempting a completely virgin install of PythonCard on my G3 >>laptop under OS X. >> >>I got machopython and wxpython-mac to install and run just fine. I >>wanted to get the cvs on PythonCard, so I ... > >>... go into my python code working directory (called pycode), and >>type the code from the pythoncard cvs site that is supposed to set up >>anonymous access. I just copy and paste it, so I'm sure the syntax is >>right. I've done this a few times. >> >>I get the following error in terminal: >> >>cvs can't open library: /usr/lib/:libgssapi_krb5.2.2.dylib (No such >>file or directory, errno = 2) >> >>My working hypothesis is that I need to install Dev Tools on this box >>to get CVS to work correctly. > >Dan -- > >I followed the same procedure you reported above a week ago to get >PythonCard 0.6.7 source and got some non-network error as you did. >I have the developer tools installed. I also have a copy of the >freeware GUI CVS program wrapper AnonymousGet . So I used it, >following as a prototype one of its preset sourceForge bookmarks. >No problems. Possibly the problem is compatibility of the >pythoncard cvs site's recommended anonymous CVS options? Since this process works fine - and always has - on my G4 tower, where I do have Dev Tools installed - I don't suspect a configuration error. >BTW, big thanks for your efforts in pythonCard documentation, it counts. Thanks for saying so! >-- Andy Wright > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- Dan Shafer, Product Development Expert Helping you turn your best ideas into products that sell http://www.danshafer.com From Jack.Jansen@oratrix.com Tue Jun 11 21:18:40 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 11 Jun 2002 22:18:40 +0200 Subject: [Pythonmac-SIG] proper include for bundled h files In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE77D@sea-horse.humongous.com> Message-ID: <6B974960-7D78-11D6-A600-003065517236@oratrix.com> On dinsdag, juni 11, 2002, at 08:38 , Magladry, Stephen wrote: > I am having problems getting the h file recognized from my CW compiles, > using a bundled Python. Here are the steps I have done. > > 1. Downloaded the Python-2.2.1.tgz from python.org > 2. Followed the directions in Mac/OSX folder to build bundled > version of > Python in the default location /Library/Frameworks. > 3. Use CodeWarrior stationary to build a C++ Toolbox Mach-O project. > 4. Add the python.framework to the newly created project. > 5. add a #include line to the MyFramework.cp file. > 6. Try to compile. Get a, "The file "python.h" cannot be > opened." error. This will not work with the current state of the Python framework, for a number of reasons. The main reason is that Python.framework is not a full-fledged framework. It is from the execution point of view (i.e. linking against it will do the right thing) but not from the compilation point of view. If it was a full framework you should be able to do #include (the capitalisation may be important), but (a) this hasn't been tested and (b) I strongly advise against this. The reason for advising against this is that all Python extensions in the world do a simple #include "Python.h", and that the organization of the Python directory structure (plus distutils, etc etc etc) is setup to support this usage. If you were to distribute something with the construct it would work only when building for OSX framework installations (and the unix crowds would start slagging us macheads for doing things incompatible, etc etc). The solution is rather simple, though. You not only add the "-framework Python" option to your build, but also "-I/Library/Frameworks/Python.framework/Headers" (or, in CW-speak, add that directory to your search path), and do #include "Python.h" everywhere. Note that there's a precedent for this from Apple too: a similar trick is needed for OpenGL programs that use GLUT (or GLU, I forget). All that said, I haven't tried using the CW Mach-O compiler to build MachoPython extensions (always used the unix tools for MachoPython), so you may run into other snags as well. Please report back here if you get it to work (or not:-). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From stephenm@humongous.com Tue Jun 11 21:57:07 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Tue, 11 Jun 2002 13:57:07 -0700 Subject: [Pythonmac-SIG] proper include for bundled h files Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE77F@sea-horse.humongous.com> Thanks for the reply. I can access the file after adding the access path to the header files. Case appears to be insignificant. I guess this leads to a bigger question on whether what I'm trying to attempt is doable. Here's what we are trying to accomplish. Currently we are developing a product. On the PC side, we use Python as our executable and call out to platform specific stuff and potential Python bottlenecks in c libraries. We have a system setup the generates the interface files so that the Python code and C code stay in sync and are callable back and forth. With Apple's drive to Mach-O and the fact that a single package would help to simplify distribution, I wanted to use the Python Bundle as our app and store the C libraries in the appropriate folder within the bundle and load them from there. Would this be advisable with the current state of the Python bundled app? With the current state of Python Mach-O, should I just fall back to Python CFM and cut my loses now? Thanks for you feedback, Stephen Magladry -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Tuesday, June 11, 2002 1:19 PM To: Magladry, Stephen Cc: 'pythonmac-sig@python.org' Subject: Re: [Pythonmac-SIG] proper include for bundled h files On dinsdag, juni 11, 2002, at 08:38 , Magladry, Stephen wrote: > I am having problems getting the h file recognized from my CW compiles, > using a bundled Python. Here are the steps I have done. > > 1. Downloaded the Python-2.2.1.tgz from python.org > 2. Followed the directions in Mac/OSX folder to build bundled > version of > Python in the default location /Library/Frameworks. > 3. Use CodeWarrior stationary to build a C++ Toolbox Mach-O project. > 4. Add the python.framework to the newly created project. > 5. add a #include line to the MyFramework.cp file. > 6. Try to compile. Get a, "The file "python.h" cannot be > opened." error. This will not work with the current state of the Python framework, for a number of reasons. The main reason is that Python.framework is not a full-fledged framework. It is from the execution point of view (i.e. linking against it will do the right thing) but not from the compilation point of view. If it was a full framework you should be able to do #include (the capitalisation may be important), but (a) this hasn't been tested and (b) I strongly advise against this. The reason for advising against this is that all Python extensions in the world do a simple #include "Python.h", and that the organization of the Python directory structure (plus distutils, etc etc etc) is setup to support this usage. If you were to distribute something with the construct it would work only when building for OSX framework installations (and the unix crowds would start slagging us macheads for doing things incompatible, etc etc). The solution is rather simple, though. You not only add the "-framework Python" option to your build, but also "-I/Library/Frameworks/Python.framework/Headers" (or, in CW-speak, add that directory to your search path), and do #include "Python.h" everywhere. Note that there's a precedent for this from Apple too: a similar trick is needed for OpenGL programs that use GLUT (or GLU, I forget). All that said, I haven't tried using the CW Mach-O compiler to build MachoPython extensions (always used the unix tools for MachoPython), so you may run into other snags as well. Please report back here if you get it to work (or not:-). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Wed Jun 12 13:17:44 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 12 Jun 2002 14:17:44 +0200 Subject: [Pythonmac-SIG] proper include for bundled h files In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE77F@sea-horse.humongous.com> Message-ID: <66284A71-7DFE-11D6-807D-0030655234CE@cwi.nl> On Tuesday, June 11, 2002, at 10:57 , Magladry, Stephen wrote: > With Apple's drive to Mach-O and the fact that a single package would > help > to simplify distribution, I wanted to use the Python Bundle as our app > and > store the C libraries in the appropriate folder within the bundle and > load > them from there. Would this be advisable with the current state of the > Python bundled app? With the current state of Python Mach-O, should I > just > fall back to Python CFM and cut my loses now? I see no reasons why this shouldn't work. But you should realise that you're treading new ground here, so you may well run into snags. Let us know how things go:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mps@utas.edu.au Thu Jun 13 14:36:37 2002 From: mps@utas.edu.au (Matthew Smith) Date: Thu, 13 Jun 2002 23:36:37 +1000 Subject: [Pythonmac-SIG] Python dieing outside project builder In-Reply-To: <66284A71-7DFE-11D6-807D-0030655234CE@cwi.nl> Message-ID: Hello, I'm linking to the python framework in an app I'm working on, the app needs to run a python script at start-up. If I run the app from inside project builder everything works and the return value for executing the script is fine. If the program is launched outside project builder (eg double-clicking on it in the finder), the script doesn't run and the return value gives an error. The script I am running is with the .app file in the build directory... Any ideas? Thanks, Matt Smith From Jack.Jansen@oratrix.com Thu Jun 13 20:41:59 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 13 Jun 2002 21:41:59 +0200 Subject: [Pythonmac-SIG] Python dieing outside project builder In-Reply-To: Message-ID: On donderdag, juni 13, 2002, at 03:36 , Matthew Smith wrote: > Hello, > > I'm linking to the python framework in an app I'm working on, > the app needs > to run a python script at start-up. > > If I run the app from inside project builder everything works > and the return > value for executing the script is fine. > > If the program is launched outside project builder (eg > double-clicking on it > in the finder), the script doesn't run and the return value > gives an error. > > The script I am running is with the .app file in the build directory... > > Any ideas? Just a wild guess: when you double-click you could have a different working directory than when you run from Project Builder. You could put some debug output in your embedding application (for instance print the working directory, or set the Py_VerboseFlag to 1 before calling Python), and the output will appear in the console window (Applications->Utilities->Console). I'm also not 100% sure which Python initialize routine you need to call if your Python scripts want access to Carbon methods. I think Py_Initialize() may be good enough, but it could be that you have to use PyMac_Initialize() (as in MacPython). Or maybe you even need something completely different (i.e. Py_Initialize() plus some of the stuff in PyMac_Initialize(). Maybe someone else has already experimented with embedding MachoPython and has information to share? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From aparente@adobe.com Thu Jun 13 20:58:20 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Thu, 13 Jun 2002 12:58:20 -0700 Subject: [Pythonmac-SIG] Python dieing outside project builder In-Reply-To: Message-ID: Mattew, I don't think the current folder should have any importance with the frameworks since the paths are hard coded at ./configure time. I'm developing from CodeWarrior BTW. Here is what I do: #elif TARGET_RT_MAC_CFM console_output_state = 1; PyMac_SetConsoleHandler(PyMac_DummyReadHandler, PyMac_DummyWriteHandler, PyMac_DummyWriteHandler); PyMacSchedParams scp; PyMac_GetSchedParams(&scp); scp.process_events = 0; PyMac_SetSchedParams(&scp); Py_SetProgramName("maccvs"); #elif TARGET_RT_MAC_MACHO Py_SetProgramName("maccvsX"); Py_Initialize(); #else I have also some code which makes sure that prior to that the current resource fork is the application one which has the 'Popt' resource inside, but I suspect it is used only with PythonCFM's Py_MacInitialize. Some more code: PyEval_InitThreads(); m_mainInterpreter = PyThreadState_Swap(NULL); PyThreadState *OLD = PyThreadState_Swap(m_mainInterpreter); PyObject *m = Py_InitModule4("_cvsgui", &gAllMethods[0], "The cvsgui glue functions", (PyObject*)NULL,PYTHON_API_VERSION); .... PyThreadState_Swap(OLD ); resource 'Popt' (PYTHONOPTIONSOVERRIDE_ID, "Options") { POPT_VERSION_CURRENT, noInspect, noVerbose, noOptimize, noUnbuffered, noDebugParser, unused_0, noCloseOutput, interactiveOptions, argcArgv, newStandardExceptions, sitePython, navService, delayConsole, noDivisionWarning, unixNewlines, }; Hope it helps, Alex. > > On donderdag, juni 13, 2002, at 03:36 , Matthew Smith wrote: > >> Hello, >> >> I'm linking to the python framework in an app I'm working on, >> the app needs >> to run a python script at start-up. >> >> If I run the app from inside project builder everything works >> and the return >> value for executing the script is fine. >> >> If the program is launched outside project builder (eg >> double-clicking on it >> in the finder), the script doesn't run and the return value >> gives an error. >> >> The script I am running is with the .app file in the build directory... >> >> Any ideas? > > Just a wild guess: when you double-click you could have a > different working directory than when you run from Project > Builder. You could put some debug output in your embedding > application (for instance print the working directory, or set > the Py_VerboseFlag to 1 before calling Python), and the output > will appear in the console window > (Applications->Utilities->Console). > > I'm also not 100% sure which Python initialize routine you need > to call if your Python scripts want access to Carbon methods. I > think Py_Initialize() may be good enough, but it could be that > you have to use PyMac_Initialize() (as in MacPython). Or maybe > you even need something completely different (i.e. > Py_Initialize() plus some of the stuff in PyMac_Initialize(). > > Maybe someone else has already experimented with embedding > MachoPython and has information to share? > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- > Emma Goldman - > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From mps@utas.edu.au Fri Jun 14 00:13:12 2002 From: mps@utas.edu.au (Matthew Smith) Date: Fri, 14 Jun 2002 09:13:12 +1000 Subject: [Pythonmac-SIG] Python dieing outside project builder In-Reply-To: Message-ID: Hello, Thanks for the help! I'm calling: Py_SetProgramName("My App"); Py_Initialize(); I then make python aware of some functions in the app. Then: VBALLOW_PYTHON = !PyRun_SimpleString("execfile(\"autoexec.py\")\n"); if (!VBALLOW_PYTHON) printf("autoexec didn't execute!\n"); Where VBALLOW_PYTHON is a bool. I'll give printing the working directory, or setting the Py_VerboseFlag to 1, though my app seems to pick up other files in the same directory ok... Also, I'm quite the python novice, but it seems that I am doing a simaler thing to yours, Alex... Thanks again, Matt > Mattew, > > I don't think the current folder should have any importance with the > frameworks since the paths are hard coded at ./configure time. I'm > developing from CodeWarrior BTW. > > Here is what I do: > > #elif TARGET_RT_MAC_CFM > console_output_state = 1; > > PyMac_SetConsoleHandler(PyMac_DummyReadHandler, PyMac_DummyWriteHandler, > PyMac_DummyWriteHandler); > > PyMacSchedParams scp; > > PyMac_GetSchedParams(&scp); > scp.process_events = 0; > PyMac_SetSchedParams(&scp); > > Py_SetProgramName("maccvs"); > #elif TARGET_RT_MAC_MACHO > Py_SetProgramName("maccvsX"); > Py_Initialize(); > #else > > I have also some code which makes sure that prior to that the current > resource fork is the application one which has the 'Popt' resource inside, > but I suspect it is used only with PythonCFM's Py_MacInitialize. > > Some more code: > > PyEval_InitThreads(); > m_mainInterpreter = PyThreadState_Swap(NULL); > > PyThreadState *OLD = PyThreadState_Swap(m_mainInterpreter); > > PyObject *m = Py_InitModule4("_cvsgui", &gAllMethods[0], > "The cvsgui glue functions", (PyObject*)NULL,PYTHON_API_VERSION); > > .... > > PyThreadState_Swap(OLD ); > > > > resource 'Popt' (PYTHONOPTIONSOVERRIDE_ID, "Options") { > POPT_VERSION_CURRENT, > noInspect, > noVerbose, > noOptimize, > noUnbuffered, > noDebugParser, > unused_0, > noCloseOutput, > interactiveOptions, > argcArgv, > newStandardExceptions, > sitePython, > navService, > delayConsole, > noDivisionWarning, > unixNewlines, > }; > > Hope it helps, > Alex. > > >> >> On donderdag, juni 13, 2002, at 03:36 , Matthew Smith wrote: >> >>> Hello, >>> >>> I'm linking to the python framework in an app I'm working on, >>> the app needs >>> to run a python script at start-up. >>> >>> If I run the app from inside project builder everything works >>> and the return >>> value for executing the script is fine. >>> >>> If the program is launched outside project builder (eg >>> double-clicking on it >>> in the finder), the script doesn't run and the return value >>> gives an error. >>> >>> The script I am running is with the .app file in the build directory... >>> >>> Any ideas? >> >> Just a wild guess: when you double-click you could have a >> different working directory than when you run from Project >> Builder. You could put some debug output in your embedding >> application (for instance print the working directory, or set >> the Py_VerboseFlag to 1 before calling Python), and the output >> will appear in the console window >> (Applications->Utilities->Console). >> >> I'm also not 100% sure which Python initialize routine you need >> to call if your Python scripts want access to Carbon methods. I >> think Py_Initialize() may be good enough, but it could be that >> you have to use PyMac_Initialize() (as in MacPython). Or maybe >> you even need something completely different (i.e. >> Py_Initialize() plus some of the stuff in PyMac_Initialize(). >> >> Maybe someone else has already experimented with embedding >> MachoPython and has information to share? >> -- >> - Jack Jansen >> http://www.cwi.nl/~jack - >> - If I can't dance I don't want to be part of your revolution -- >> Emma Goldman - >> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > -- "Many that live deserve death. And some die that deserve life. Can you give that to them? Then be not too eager to deal out death in the name of justice, fearing for your own safety. Even the wise cannot see all ends." JRR Tolkien, The Two Towers - The Lord of the Rings. From alexp@strata.com Fri Jun 14 00:27:59 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Thu, 13 Jun 2002 16:27:59 -0700 Subject: [Pythonmac-SIG] Python dieing outside project builder In-Reply-To: Message-ID: > if (!VBALLOW_PYTHON) > printf("autoexec didn't execute!\n"); Why don't you try: if (!VBALLOW_PYTHON) PyErr_Print(); It might at least give you a diagnostic, but you need to run it from a shell in order to see the output since PyErr_Print() is using sys.stderr, which at initialization time is set up to use stderr. Alex. From Jack.Jansen@cwi.nl Fri Jun 14 14:23:31 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 14 Jun 2002 15:23:31 +0200 Subject: [Pythonmac-SIG] Python, Jython, Cocoa and Charleroi In-Reply-To: <1023126232.3cfbaad8807c5@webmail.in-berlin.de> Message-ID: On Monday, June 3, 2002, at 07:43 , Dinu Gherman wrote: > Jython and Cocoa could work very nicely together! Apple has an > equivalent Java API for its frameworks and I find it to be more > natural to use than anything pyobjc-like that I've seen so far, > one reason being that it doesn't result in plenty of underscores > and parantheses that seem to be needed for simulating Objective- > C's method signatures in Python. What's the convention used by Apple's Java<->ObjC bridge? I don't like all the underscores either, and if Apple decided not to do any underscores I think pyobjc should follow suit. It could always have a compile-time option to give the old _ names, for backward compatibility. > Also, pyobjc development seems to be more or less stalled (?), so > I've never been sure what to expect from that side in the not so > distant future. Well, as mentioned here before there's now three of us happily hacking at it. Unfortunately the folks over at the pyobjc mailing list are in deep slumber: two of my mails are still waiting in their mail queue (and have been for almost 2 weeks now) and a message directly to Steven Majevski has also remained unanswered, so I think he's off on holidays or otherwise occupied. > I've added below some of the most simple test functions from my > growing test suite just to give you an idea... Do you have an example of a Jython program with a NIB? That's what we're currently working on for pyobjc, and we're getting some positive results (we have a Python applet with a .nib and it fills an on-screen table with data from a Python table source object (just before crashing hard:-)), but it would be nice to see how things are done in Jython. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 14 14:29:19 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 14 Jun 2002 15:29:19 +0200 Subject: [Pythonmac-SIG] machopython crash on MOSX In-Reply-To: Message-ID: On Thursday, June 6, 2002, at 09:33 , lists wrote: > Yo, > > I'm not sure wether I should post this directly to the list of enter a > as bug somewhere. > If it needs to be filed as a bug I'd gladly to it, if someone would be > kind enough to point me to instructions on how to do it. > > I've just had a crash (segmentation fault) in machopython. > > I'm using version 2.2.1 compiled (on MOSX 10.1.4) from source and > installed as a framework. > I've upgraded to 10.1.5 but dunno if it's related. > The crash is totally reproducible OMM. > > At the python prompt type: > > help() > modules dbm > > It crashes while generating the list of dbm modules: I cannot repeat this. But I have an idea: are you by any chance logged in remotely to your OSX machine? The crash you get (if you look at the stack trace) is in the initializer routine of a just loaded dynamically linked module. And we have the outstanding bug that if you try to import a module that uses the window server (such as any Carbon module) if you have no right to access the window server you get a hard crash. And help() will often import any module it can see. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 14 14:41:40 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 14 Jun 2002 15:41:40 +0200 Subject: [Pythonmac-SIG] MacPython vs. Python In-Reply-To: <0D4C7B00-7A6B-11D6-855D-003065FBF976@curtisg.net> Message-ID: <749EBAA0-7F9C-11D6-BA39-0030655234CE@cwi.nl> On Saturday, June 8, 2002, at 01:05 , Curtis Galloway wrote: > Hi all. I am a longtime Python user on various flavors of UNIX but am > relatively new to the Mac world. My only experience has been with OS > X, so I am somewhat ignorant about the OS 9 world. > > I'm interested in wrapping OS X frameworks like CoreFoundation so I can > use them from Python. I see that MacPython has wrapped versions, and I > also saw something somewhere that said people are working on merging > MacPython into the rest of Python. If you grab Python from CVS you'll see that the CoreFoundation wrappers are a lot more finished than they were at the time of 2.2.1, I've put quite some work into them lately. And they should work both under MacPython and under MachoPython (but you'll have to make a --enable-framework Python on the latter). > Who's working on that? What's the status? Can I help? I apologize if > this is a frequently asked question. Wish it were, wish it were... :-) But if you're willing to help: what I need most at the moment (wrt CoreFoundation) is feedback. Which bits are missing, is the functionality exposed in a reasonable way, etc. And if you want to write code: here's my TODO list as far as CoreFoundation goes. Feel free to beat me to it. First thing is I want to check whether I can now turn .plist files into Python objects and vice versa. If that works I want to adapt BuildApplet.py to build the applet's plist file by reading/modifying Python.app's plist file (in stead of having a silly almost-copy of the plist file for applets in the Python.app bundle). That should also enable us to put custom .icns files in there, etc. Next come preferences. If the CF implementation is good enough to handle CFPreferences Python (and EditPythonPrefs) should move that way. First thing to fix would be the IDE preferences, since that is already pretty close to the CFPreferences model. If those work then EditPythonPrefs.py and macmain.c:init_common() (and pythonresources.h, and a few more minor places) need to be fixed to use the IDE preferences module and CFPreferences, respectively. So have your pick, I would say! -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 14 14:48:20 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 14 Jun 2002 15:48:20 +0200 Subject: [Pythonmac-SIG] Re: EditPythonPrefs In-Reply-To: <20020606201837.G21216@skuba.h--y.com> Message-ID: <632A8AD3-7F9D-11D6-BA39-0030655234CE@cwi.nl> On Thursday, June 6, 2002, at 11:18 , Jacek Artymiak wrote: > I have encountered a problem with MacPython 2.2.1 that I seem unable to > solve on my own. > > The machine I am trying to install MacPython on has 192MB RAM and two > disk partitions, one for Mac OS 9 and another for Mac OS X. I try to > install MacPython under Mac OS X, all goes well, I run > ConfigurePythonClassic, nothing wrong here either. But when I run > EditPythonPrefs, after I click on the OK button, the dialog disappears, > as would be expected, but the preferences are not changed to new > values. What could be wrong? I tried this on a machine with a similar setup (OS9 and OSX on separate partitions) and I have no problem. I tried both changing sys.path and changing one of the startup options, and everything worked fine. Unless I get more reports of this I'm inclined to think it's something with your setup (maybe you're logged in as a user who somehow doesn't have permission to write in the OS9 system folder?). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 14 14:52:24 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 14 Jun 2002 15:52:24 +0200 Subject: [Pythonmac-SIG] Python and Jaguar In-Reply-To: <1023710195.3d0493f349f89@webmail.in-berlin.de> Message-ID: On Monday, June 10, 2002, at 01:56 , Dinu Gherman wrote: > I heard that Jaguar (OS X 10.2) finally comes with > Python 2.2 bundled, but I don't have any developer > prerelease of it, so I can only guess it's a Unix > compile of 2.2.1. Has anybody already been riding > on it to give more details? If people haven't answered this because of their non-disclosure-agreement: please let me know in private (I'm a developer, you can trust me:-). I would be especially interested in knowing whether they've included a framework-build or a non-framework-build. That's because if they did a framework build I'd better quickly check that the stuff that has multiple versions in the one framework actually works, or people will be in for a nasty shock if they download and install Python 2.3 on MacOS 10.2 some time later this year... (I haven't installed Jaguar myself yet as I have no partition to spare right now). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From brownr@ucalgary.ca Fri Jun 14 18:08:21 2002 From: brownr@ucalgary.ca (Robb Brown) Date: Fri, 14 Jun 2002 11:08:21 -0600 Subject: [Pythonmac-SIG] Python can't find dylibs on OSX Message-ID: I've run into a problem when importing the VTK vtkTkRenderWidget -- libvtkRenderingPythonTkWidget.dylib is not found. Not surprising since dyld is looking in the working directory for it. I have my DYLD_LIBRARY_PATH set appropriately. Is there another environment variable that should be set? Also, more of a question for the VTK list but if anyone happens to know, if I switch to a directory with vtkTkRenderWidget.dylib file and try and use it, I get a dyld: /Applications/Python.app/Contents/MacOS/python Undefined symbols: _Vtkrenderingpythontkwidgets_SafeInit error. Is anyone successfully using VTK's Tk widgets under Aqua with Python? Thanks, -- ______________________________ Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada From altis@semi-retired.com Fri Jun 14 20:14:20 2002 From: altis@semi-retired.com (Kevin Altis) Date: Fri, 14 Jun 2002 12:14:20 -0700 Subject: [Pythonmac-SIG] CGIHTTPServer problems on OS X Message-ID: I've been trying to use a variation of the basic built-in Python web server like this: import os from BaseHTTPServer import HTTPServer from CGIHTTPServer import CGIHTTPRequestHandler os.chdir("html") # my hostname, portnumber srvraddr = ('', 80) srvrobj = HTTPServer(srvraddr, CGIHTTPRequestHandler) # run as perpetual demon srvrobj.serve_forever() The actual code I'm testing is the GUI front-end included with PythonCard, but this problem seems to be with CGIHTTPServer not wxPython or any GUI code. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp e/samples/webserver/ Serving files works fine, but I can't get CGIs to work. The error I'm getting is (partial traceback) CGIHTTPServer, line 65, in send_head, return self.run_cgi() CGIHTTPServer, line 196, in run_cgi, self.rfile.flush() # Always flush before forking IOError: [Errno 9] Bad file descriptor I'm using the latest MachoPython build from: http://sourceforge.net/project/showfiles.php?group_id=10718 BTW, if you run at a low port number like 80, you'll have to use sudo to start the server, so it might be simpler to try a high port like 8000. Are simple CGIs are working for other people using the Python built-in libraries? ka ---------------------- Kevin Altis altis@semi-retired.com From Robin.Siebler@corp.palm.com Fri Jun 14 23:07:46 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Fri, 14 Jun 2002 15:07:46 -0700 Subject: [Pythonmac-SIG] Autocompletion Message-ID: <400CE9390E334A4393CEECDD6863120A0412FC85@ussccm003.corp.palm.com> I tried the Python IDE and BBEdit and neither seem to have autocompletion. Is there something I have to do to get this, is there something else I should use, or am I just SOL? Robin L. Siebler Software Test Engineer Palm -------------------------------- Garunteed to be bug free From Jack.Jansen@oratrix.com Sat Jun 15 23:20:57 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 16 Jun 2002 00:20:57 +0200 Subject: [Pythonmac-SIG] CGIHTTPServer problems on OS X In-Reply-To: Message-ID: <2A16E28C-80AE-11D6-9071-003065517236@oratrix.com> On vrijdag, juni 14, 2002, at 09:14 , Kevin Altis wrote: > Serving files works fine, but I can't get CGIs to work. The error I'm > getting is (partial traceback) Have you tried this on another Unix or Linux system? I would be surprised if it was an OSX-specific issue (but then, I'm surprised easily;-). If you can pack up this file plus a sample cgi script in the html directory (i.e. create a tarfile that I can simply unpack and run without understanding what I'm doing) I can have a look. It would be best if you submitted it to the sourceforge bug reporter. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gherman@darwin.in-berlin.de Mon Jun 17 08:46:53 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 17 Jun 2002 09:46:53 +0200 Subject: [Pythonmac-SIG] Python, Jython, Cocoa and Charleroi References: Message-ID: <3D0D93ED.EAC4806@darwin.in-berlin.de> Jack Jansen wrote: > > What's the convention used by Apple's Java<->ObjC bridge? I don't > like all the underscores either, and if Apple decided not to do > any underscores I think pyobjc should follow suit. It could always > have a compile-time option to give the old _ names, for backward > compatibility. I'm not sure there is a formal convention. Obj-C signatures are "richer" in a sense that you can say: [obj doItWithFoo:arg1 andBar:arg2 andQuit]; which in Java would probably become: obj.doItWithFooAndBarAndQuit(arg1, arg2); The Java Cocoa-API tries hard to come as close as possible to the "original meaning" of Obj-C signatures, but in some cases this might be difficult to achieve. > Well, as mentioned here before there's now three of us happily > hacking at it. Unfortunately the folks over at the pyobjc mailing > list are in deep slumber: two of my mails are still waiting in > their mail queue (and have been for almost 2 weeks now) and a > message directly to Steven Majevski has also remained unanswered, > so I think he's off on holidays or otherwise occupied. Yes, I meant the pyobjc mailing list which looked, uhm, coma- tose. If you have something to play with I might want to give it a try, perhaps. > Do you have an example of a Jython program with a NIB? That's what > we're currently working on for pyobjc, and we're getting some posi- > tive results (we have a Python applet with a .nib and it fills an > on-screen table with data from a Python table source object (just > before crashing hard:-)), but it would be nice to see how things > are done in Jython. Well I have some trivial code, but it doesn't work! ;-) Most likely, that's because of some problem in establishing a re- cognized owner relationship and providing the callable methods in the owner (omitted in the next snippet): result = NSApplication.loadNibNamed("AlertPanel", owner) OTOH, some other trivial code *does* work (well, "most of the time", as there seem to be some Jython issues left to meditate over as well...). See below. Regards, Dinu # watchLuxoJr.py import sys sys.path.append("/System/Library/Java") from java.net import URL from com.apple.cocoa.foundation import * from com.apple.cocoa.application import * from com.apple.cocoa.application.NSWindow \ import TitledWindowMask, ClosableWindowMask, Buffered class Cinema: def fetch(self, url): self.movie = NSMovie(URL(url), 0) def show(self, format): width, height = format winRect = NSRect(100, 200, width, height) myView = NSMovieView() myView.setMovie(self.movie) myStyle = TitledWindowMask | ClosableWindowMask myWindow = NSWindow(winRect, myStyle, Buffered, 0) myWindow.setContentView(myView) myWindow.makeKeyAndOrderFront(None) myView.gotoBeginning(self) myView.start(self) def main(): url = 'http://www.pixar.com/theater/shorts/ljr/quicktime/ljr_180.mov' format = (180, 116) c = Cinema() c.fetch(url) c.show(format) myPool = NSAutoreleasePool.push() app = NSApplication.sharedApplication() main() app.run() NSAutoreleasePool.pop(myPool) sys.exit(0) From lee.list@joramo.com Mon Jun 17 16:54:34 2002 From: lee.list@joramo.com (Lee Joramo) Date: Mon, 17 Jun 2002 09:54:34 -0600 Subject: [Pythonmac-SIG] Autocompletion In-Reply-To: <400CE9390E334A4393CEECDD6863120A0412FC85@ussccm003.corp.palm.com> Message-ID: There is a BBEdit plug in that may give you some of the functionality that you want: It is listed at VersionTracker: -- Lee Joramo Twenty plus years of multi-platform computing TRS-80>LDOS>Apple][>CPM>MSDOS>DesqView>W3.1>OS/2>MacOS>W95>Linux>BSD>MacOSX Are We there yet? On 6/14/02 4:07 PM, "Robin Siebler" wrote: > I tried the Python IDE and BBEdit and neither seem to have autocompletion. > Is there something I have to do to get this, is there something else I > should use, or am I just SOL? From tony@lownds.com Mon Jun 17 17:15:21 2002 From: tony@lownds.com (Tony Lownds) Date: Mon, 17 Jun 2002 09:15:21 -0700 Subject: [Pythonmac-SIG] CGIHTTPServer problems on OS X In-Reply-To: <2A16E28C-80AE-11D6-9071-003065517236@oratrix.com> References: <2A16E28C-80AE-11D6-9071-003065517236@oratrix.com> Message-ID: At 12:20 AM +0200 6/16/02, Jack Jansen wrote: >On vrijdag, juni 14, 2002, at 09:14 , Kevin Altis wrote: > >>Serving files works fine, but I can't get CGIs to work. The error I'm >>getting is (partial traceback) > >Have you tried this on another Unix or Linux system? I would be >surprised if it was an OSX-specific issue (but then, I'm surprised >easily;-). > It's probably a BSD-specific issue... it doesn't affect Linux (I just tried both). CGIHTTPServer.py calls the flush method on a file descriptor open for reading. That in turn does a fflush(3) call, which is documented to cause an error in this case: man fflush: ERRORS [EBADF] Stream is not an open stream, or, in the case of fflush(), not a stream open for writing. On my Linux box, fflush is also documented to cause an error on files not open for writing, so I guess in practice the C library doesn't act that way. I think the correct fix is to remove the self.rfile.flush() line from CGIHTTPServer.py -Tony Index: CGIHTTPServer.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/CGIHTTPServer.py,v retrieving revision 1.25 diff -u -r1.25 CGIHTTPServer.py --- CGIHTTPServer.py 1 Jun 2002 19:51:15 -0000 1.25 +++ CGIHTTPServer.py 17 Jun 2002 16:09:22 -0000 @@ -193,7 +193,6 @@ if '=' not in decoded_query: args.append(decoded_query) nobody = nobody_uid() - self.rfile.flush() # Always flush before forking self.wfile.flush() # Always flush before forking pid = os.fork() if pid != 0: From goodmansond@yahoo.com Mon Jun 17 23:41:12 2002 From: goodmansond@yahoo.com (Dean Goodmanson) Date: Mon, 17 Jun 2002 15:41:12 -0700 (PDT) Subject: [Pythonmac-SIG] FWD: [Zope-Annce] New Zope-MOSX portal/mailing list Message-ID: <20020617224112.86611.qmail@web21102.mail.yahoo.com> ------------------------------------------ Date: Thu, 6 Jun 2002 15:20:04 -0500 To: zope-announce @ zope.org From: Steve Spicklemire Subject: [Zope-Annce] New Zope-MOSX portal/mailing list is born.. Silicon Prairie Ventures is pleased to announce a new mailing list and CMF portal for Macintosh OS X Zope users: The mailing list is found: Zope-MOSX- list ( http://www.zopeonarope.com/mailman/listinfo/zope-mosx ) The portal is here: Zope-MOSX-portal ( http://zope-mosx.zopeonarope.com ) The list (and portal) are devoted to the discussion OS X specific Zope topics in the following areas (and more!): Development & Distribution (on MOSX) Administration (on MOSX.. you get the idea) Support modules and tools Zope product porting issues Applications and Environment Gathering Zope on OS X FAQ's ------------------------------------------ __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From burrda@mac.com Tue Jun 18 03:55:33 2002 From: burrda@mac.com (L. Daniel Burr) Date: Mon, 17 Jun 2002 22:55:33 -0400 Subject: [Pythonmac-SIG] SSL, client certificates, proxy authorization Message-ID: Could somebody please give me some advice regarding SSL communications and XML-RPC? The scenario is as follows: - I have a python client behind a firewall - There is a proxy server that requires authorization - There is an external XML-RPC server, using SSL on port 443 - The XML-RPC server requires that I use client certificate authentication Now, I can use xmlrpclib over HTTP, pass the Proxy-Authorization header to the proxy, and access external XML-RPC servers (Meerkat, for example) that are not encrypted. So far so good. I can also perform HTTPS requests through the proxy to external HTTPS servers. The problem occurs when I need to create an HTTPSConnection that uses a client certificate to authenticate against the SSL-based XML-RPC server. I can't seem to figure out how to make the proxy forward my request to the XML-RPC server. I think I need to somehow make the proxy perform its SSL tunneling function (HTTP CONNECT method), but I can't see how to accomplish this. If I have an HTTPConnection to the proxy, how do I overlay it with an SSL connection, along with the client certificate? I've scoured the web and found one helpful HTTPS-with-client-certs recipe in the Python Cookbook, but nothing about how to get python to do this through a proxy. The client is running on Mac OS 10.1.5, machopython 2.2.1_3 (from the wxpython site). Any suggestions would be very much appreciated. L. Daniel Burr From Jack.Jansen@oratrix.com Tue Jun 18 13:16:08 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 18 Jun 2002 14:16:08 +0200 Subject: [Pythonmac-SIG] CGIHTTPServer problems on OS X In-Reply-To: Message-ID: <2B4FC75E-82B5-11D6-951C-003065517236@oratrix.com> Tony, your analysis makes sense to me, but I assume someone (who may know better) put that fflush() in there. Could you post this fix to sourceforge as a bug report, so someone with a more intimate understanding of CGIhttpserver.py can look at it? I have no idea who to assign it to, maybe Guido? On maandag, juni 17, 2002, at 06:15 , Tony Lownds wrote: > At 12:20 AM +0200 6/16/02, Jack Jansen wrote: >> On vrijdag, juni 14, 2002, at 09:14 , Kevin Altis wrote: >> >>> Serving files works fine, but I can't get CGIs to work. The error I'm >>> getting is (partial traceback) >> >> Have you tried this on another Unix or Linux system? I would >> be surprised if it was an OSX-specific issue (but then, I'm >> surprised easily;-). >> > > It's probably a BSD-specific issue... it doesn't affect Linux > (I just tried both). CGIHTTPServer.py calls the flush method on > a file descriptor open for reading. That in turn does a > fflush(3) call, which is documented to cause an error in this > case: > > man fflush: > > ERRORS > [EBADF] Stream is not an open stream, or, in > the case of > fflush(), not a stream open for writing. > > On my Linux box, fflush is also documented to cause an error on > files not open for writing, so I guess in practice the C > library doesn't act that way. > > I think the correct fix is to remove the self.rfile.flush() > line from CGIHTTPServer.py > > -Tony > > > Index: CGIHTTPServer.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/CGIHTTPServer.py,v > retrieving revision 1.25 > diff -u -r1.25 CGIHTTPServer.py > --- CGIHTTPServer.py 1 Jun 2002 19:51:15 -0000 1.25 > +++ CGIHTTPServer.py 17 Jun 2002 16:09:22 -0000 > @@ -193,7 +193,6 @@ > if '=' not in decoded_query: > args.append(decoded_query) > nobody = nobody_uid() > - self.rfile.flush() # Always flush before forking > self.wfile.flush() # Always flush before forking > pid = os.fork() > if pid != 0: > > > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony@lownds.com Tue Jun 18 18:03:45 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 18 Jun 2002 10:03:45 -0700 Subject: [Pythonmac-SIG] CGIHTTPServer problems on OS X In-Reply-To: <2B4FC75E-82B5-11D6-951C-003065517236@oratrix.com> References: <2B4FC75E-82B5-11D6-951C-003065517236@oratrix.com> Message-ID: At 2:16 PM +0200 6/18/02, Jack Jansen wrote: >Tony, >your analysis makes sense to me, but I assume someone (who may know >better) put that fflush() in there. Could you post this fix to >sourceforge as a bug report, so someone with a more intimate >understanding of CGIhttpserver.py can look at it? Sure, will do.... bug 570678. >I have no idea who to assign it to, maybe Guido? I can't assign it anyway. FWIW Guido checked in the change: 1.19 (gvanross 17-Oct-01): self.rfile.flush() # Always flush before forking -Tony From Jack.Jansen@oratrix.com Tue Jun 18 23:07:26 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 19 Jun 2002 00:07:26 +0200 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! Message-ID: Folks, we've just succeeded in creating the first Python applet (we think, you can never be sure about the "first" bit:-) that is awakened from a NIB file built with Interface Builder. The code is all pretty messy (both the Python code and the ObjC code), but at least it seems to work. If you want to have a look at this: get http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz, read the README and play away! If had very limited success (none, actually) reaching the pyobjc crowd the last few weeks, so I suggest that discussion of this beast take place on pythonmac-sig@python.org with a cc to Pyobjc- dev@lists.sourceforge.net, for the time being. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From meatpoet@sciarc.edu Wed Jun 19 09:52:02 2002 From: meatpoet@sciarc.edu (Christian Spicher) Date: Wed, 19 Jun 2002 01:52:02 -0700 Subject: [Pythonmac-SIG] mailing list Message-ID: <97E4C25A09BE27478D5FDC10E2F1B23E2D40B0@exchange.sciarc.edu> Would like to be on the list... Meatpoet@sciarc.edu Gracias, Christian From bfancher@mac.com Wed Jun 19 17:23:40 2002 From: bfancher@mac.com (bill fancher) Date: Wed, 19 Jun 2002 09:23:40 -0700 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: Message-ID: On Tuesday, June 18, 2002, at 03:07 PM, Jack Jansen wrote: > Folks, > we've just succeeded in creating the first Python applet (we think, you > can never be sure about the "first" bit:-) that is awakened from a NIB > file built with Interface Builder. > > The code is all pretty messy (both the Python code and the ObjC code), > but at least it seems to work. Indeed it does. Well done! > If you want to have a look at this: get http://www.cwi.nl/ftp/jack/python/ > mac/nibpythonexample.tar.gz, read the README and play away! It might be worth dumping the "build" directory from the CurrencyConverter project since it constitutes the bulk of the download and will be regenerated by PB. ("Clean" in PB doesn't really make things very clean.) Haven't really had a chance to get into the code yet, but look forward to doing so. Thanks to all involved. -- bill From stephenm@humongous.com Wed Jun 19 18:53:07 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Wed, 19 Jun 2002 10:53:07 -0700 Subject: [Pythonmac-SIG] error trying to run c extension from carbon Python Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE794@sea-horse.humongous.com> I am trying to run a c extension for a build of Python Carbon and when I try to import the c extension, I get a "Interpreter not initialized (version mismatch?)" error. Here's a run down of what I have done. 1. Tried to use stock Carbon Python. It isn't even able to import a new sample library. It come back with a syntax error, some kind of stdin error if I remember correctly. 2. Needed to modify the Carbon project. As built, It doesn't support Dynamic Loading. I added the three options USE_MAC_SHARED_LIBRARIES, USE_MAC_APPLETE_SUPPORT and HAVE_DYNAMIC_LOADING. 2.5 Also use the call PYMac_Initialize() instead of PY_Initialize(). 3. Add the necessary supporting c files in order to get Carbon Python with the above library support linking. 3.5 Use dyload_mac.c in place of dynload_stub.c. 4. Rebuild PythonCarbonCore using the config.h files as the above project. 5. Build a simple c extension that weak links to the newly created PythonCarbonCore. 6. Move the new created, PythonCarbonApp, PythonCarbonCore and myLibrary to the same folder. 7. Fire up The Python interpreter. 8. Enter the command Import myLibrary, with the library file named "myLibrary.carbon.slb". 9. Get the error "Interpreter not initialized (version mismatch?)". I have stepped through the code at the interpreter level and the last line of code that gets executed, at least at the interpreter level is GetDiskFragment, line 86 in dynload_mac.c. If I try to step over this line of code, I get the error. Questions: 1. Anyone know why I'm getting this error? It doesn't seem like I have a version mismatch since everything is running off the same code base. 2. Does anyone see something glaring that I have done wrong? 3. Has anyone been able to set up a Python Carbon that is able to call c extensions? 4. Is it even possible in the current state to have the Carbon code call a c extensions? Thanks for your time, Stephen Magladry From marcus.h.mendenhall@vanderbilt.edu Thu Jun 20 17:52:44 2002 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Thu, 20 Jun 2002 11:52:44 -0500 Subject: [Pythonmac-SIG] Python embedding in LabVIEW on Mac? In-Reply-To: <20020620160002.7186.82674.Mailman@mail.python.org> References: <20020620160002.7186.82674.Mailman@mail.python.org> Message-ID: Hi, All. I recently came across a need to access Python code from inside of LabVIEW to do some data analysis. Under LabVIEW 6i for Windows, calling Py_Initialize works fine. Using LabVIEW 5.0.1 under MacOS 8.x and 9.x (OK, I haven't updated my LabVIEW install yet to anything approaching current... anyone know if it is OK under LV6 for Mac?) calling Py_Initialize results in LabVIEW quietly exiting. It appears that ExitToShell() is called, since there is no sign of of a crash. Under what conditions does Py_Initialize fail in such a way? I have tried starting LabVIEW from various directories, including the one containing PythonCore, in case paths are bad resulting in inability to find resources. If have also called Py_SetProgrameName before PyInitialize, with the full path to PythonCore as the name, just in case that would help. No luck. Since it is likely a quite painful process to follow through the innards of LabVIEW with a debugger, it seems more likely to be fixable by following through the Python startup. Thanks for any ideas anyone might have, before I waste a lot of time poking around my self rather blindly. Marcus Mendenhall Vanderbilt University Free Electron Laser Center From marcus.h.mendenhall@vanderbilt.edu Thu Jun 20 17:58:43 2002 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Thu, 20 Jun 2002 11:58:43 -0500 Subject: [Pythonmac-SIG] Python embedding in LabVIEW on Mac? (oops, found part of the problem) Message-ID: >Hi, All. > >I recently came across a need to access Python code from inside of >LabVIEW to do some data analysis. Under LabVIEW 6i for Windows, >calling Py_Initialize works fine. Using LabVIEW 5.0.1 under MacOS >8.x and 9.x (OK, I haven't updated my LabVIEW install yet to >anything approaching current... anyone know if it is OK under LV6 >for Mac?) calling Py_Initialize results in LabVIEW quietly exiting. >It appears that ExitToShell() is called, since there is no sign of >of a crash. > >Under what conditions does Py_Initialize fail in such a way? I have >tried starting LabVIEW from various directories, including the one >containing PythonCore, in case paths are bad resulting in inability >to find resources. If have also called Py_SetProgrameName before >PyInitialize, with the full path to PythonCore as the name, just in >case that would help. No luck. > >Since it is likely a quite painful process to follow through the >innards of LabVIEW with a debugger, it seems more likely to be >fixable by following through the Python startup. > >Thanks for any ideas anyone might have, before I waste a lot of time >poking around my self rather blindly. > >Marcus Mendenhall >Vanderbilt University Free Electron Laser Center OK, in response to my own post (sorry), I found an oops involving calling Py_Initialize instead of PyMac_Initialize . Now, LabVIEW gets much farther into the embedding startup, but still doesn't quite work. The remaining, important question is whether any has had this work under newer version of LabVIEW, since the 5.0.1 release is quite old. thanks again. Marcus Mendenhall From Jack.Jansen@oratrix.com Thu Jun 20 21:09:36 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Jun 2002 22:09:36 +0200 Subject: [Pythonmac-SIG] Python embedding in LabVIEW on Mac? (oops, found part of the problem) In-Reply-To: Message-ID: On donderdag, juni 20, 2002, at 06:58 , Marcus H. Mendenhall wrote: > OK, in response to my own post (sorry), I found an oops > involving calling Py_Initialize instead of PyMac_Initialize . > Now, LabVIEW gets much farther into the embedding startup, but > still doesn't quite work. The remaining, important question > is whether any has had this work under newer version of > LabVIEW, since the 5.0.1 release is quite old. Calling PyMac_Initialize() in stead of Py_Initialize() is definitely needed when embedding MacPython. But even then there are probably pitfalls. Some I can think of: - the two event loops (MacPython's and LabVIEW's) may get in each others way. Also, if you have windows open in both you may get a continuous stream of Update Events for a window which your event loop knows nothing about. - Python may have problems with missing some of the resources it needs (to find the initial sys.path and other preferences and such). Check :Mac:Demo:embed.html for some of the details (but it is by no means complete). - It may help to set Py_VerboseFlag to 1 (or 2 for even more output) before calling PyMac_Initialize. This'll give all sorts of debug output for importing modules and such. But: if your problem is eventloop/window/IO-system related this'll probably not work. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Jun 20 21:16:34 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Jun 2002 22:16:34 +0200 Subject: [Pythonmac-SIG] error trying to run c extension from carbon Python In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE794@sea-horse.humongous.com> Message-ID: <9E3C55D8-848A-11D6-A437-003065517236@oratrix.com> Stephen, are you extending Python (building a new module to be imported) or embedding Python (putting the whole interpreter into another program)? Some of the things you mention are used for embedding only (calls to PyMac_Initialize and such) but in other places you're referrring to failures to import something. If you're extending Python: you don't need to recompile anything (except your extension module, of course), if you take the standard MacPython binary installer and also select the "developer" option (not selected with the easy install) you should be all set. If you also use distutils to build your extension you should have no problems whatsoever. If you're embedding Python you may not need source either: you just call PyMac_Initialize() and then you can do any call you want. You want to read both the "embedding" section of the standard Python docs and :Mac:Demo:embed.html from the MacPython distribution. On woensdag, juni 19, 2002, at 07:53 , Magladry, Stephen wrote: > I am trying to run a c extension for a build of Python Carbon > and when I try > to import the c extension, I get a "Interpreter not initialized > (version > mismatch?)" error. Here's a run down of what I have done. > > 1. Tried to use stock Carbon Python. It isn't even able to import a new > sample library. It come back with a syntax error, some kind of > stdin error > if I remember correctly. > 2. Needed to modify the Carbon project. As built, It doesn't > support Dynamic > Loading. I added the three options USE_MAC_SHARED_LIBRARIES, > USE_MAC_APPLETE_SUPPORT and HAVE_DYNAMIC_LOADING. > 2.5 Also use the call PYMac_Initialize() instead of PY_Initialize(). > 3. Add the necessary supporting c files in order to get Carbon > Python with > the above library support linking. > 3.5 Use dyload_mac.c in place of dynload_stub.c. > 4. Rebuild PythonCarbonCore using the config.h files as the > above project. > 5. Build a simple c extension that weak links to the newly created > PythonCarbonCore. > 6. Move the new created, PythonCarbonApp, PythonCarbonCore and > myLibrary to > the same folder. > 7. Fire up The Python interpreter. > 8. Enter the command Import myLibrary, with the library file named > "myLibrary.carbon.slb". > 9. Get the error "Interpreter not initialized (version mismatch?)". > > I have stepped through the code at the interpreter level and > the last line > of code that gets executed, at least at the interpreter level is > GetDiskFragment, line 86 in dynload_mac.c. If I try to step > over this line > of code, I get the error. > > Questions: > > 1. Anyone know why I'm getting this error? It doesn't seem like > I have a > version mismatch since everything is running off the same code base. > 2. Does anyone see something glaring that I have done wrong? > 3. Has anyone been able to set up a Python Carbon that is able > to call c > extensions? > 4. Is it even possible in the current state to have the Carbon > code call a c > extensions? > > > Thanks for your time, > > > Stephen Magladry > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From marcus.h.mendenhall@vanderbilt.edu Thu Jun 20 22:49:08 2002 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Thu, 20 Jun 2002 16:49:08 -0500 Subject: [Pythonmac-SIG] Python embedding in LabVIEW on Mac? (oops, found part of the problem) In-Reply-To: References: Message-ID: >On donderdag, juni 20, 2002, at 06:58 , Marcus H. Mendenhall wrote: >>OK, in response to my own post (sorry), I found an oops involving >>calling Py_Initialize instead of PyMac_Initialize . Now, LabVIEW >>gets much farther into the embedding startup, but still doesn't >>quite work. The remaining, important question is whether any has >>had this work under newer version of LabVIEW, since the 5.0.1 >>release is quite old. > >Calling PyMac_Initialize() in stead of Py_Initialize() is definitely >needed when embedding MacPython. But even then there are probably >pitfalls. Some I can think of: >- the two event loops (MacPython's and LabVIEW's) may get in each >others way. Also, if you have windows open in both you may get a >continuous stream of Update Events for a window which your event >loop knows nothing about. >- Python may have problems with missing some of the resources it >needs (to find the initial sys.path and other preferences and such). >Check :Mac:Demo:embed.html for some of the details (but it is by no >means complete). >- It may help to set Py_VerboseFlag to 1 (or 2 for even more output) >before calling PyMac_Initialize. This'll give all sorts of debug >output for importing modules and such. But: if your problem is >eventloop/window/IO-system related this'll probably not work. Thanks, Jack. I made some progress, but I will not spend a lot of time before I get my LabVIEW update. Using PyMac_Initialize results in the embedded python session working (I can run a dumb script which opens a file, writes 'hello world' to it, and closes it). However, even if the interpreter opened no windows (that I can see), LabVIEW 5.0 pops up an internal error from its window handler and exits as soon as control returns to LabVIEW from Python. Even if the interpreter doesn't make any windows appear, does it silently mess with anything in the windowing setup? Leave the current grafPort pointing so something odd? etc.? Marcus From stephenm@humongous.com Fri Jun 21 02:24:47 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Thu, 20 Jun 2002 18:24:47 -0700 Subject: [Pythonmac-SIG] error trying to run c extension from carbon P ython Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE79B@sea-horse.humongous.com> Thanks for getting me straighten out. I am able to get my sample c library, named cheese, executing in the release build. I need to be able to build a slightly stripped down version of Python, though. So I grabbed the source archive from the Mac Python Site. I started with the PythonStandalone.mcp and made the following changes; -change gusi access paths to my access path -change use of GUSI_Core.CW6.Carb.Lib to GUSI_Core.CW7.Carb.Lib -change use of GUSI_MSL.CW6.Carb.Lib to GUSI_MSL.CW7.Carb.Lib -create new prefix file mwerks_HEcarbon_config.h -change prefix file mwerks_nscarbon_config.h to mwerks_HEcarbon_config.h -in mwerks_HEcarbon_config.h file turn off USE_TOOLBOX, USE_QT, USE_WASTE, USE_IMG, USE_GDBM, USE_ZLIB, USE_IC, USE_PYEXPAT -turn off source files and libs I don't need because of above setting -don't need dbmmodule.c file -don't need zlibmodule.c file -don't need any Extension:img -don't need any img libraries -don't need pyexpat.c -dont need modulewaste.c -don't need gdbm.pcc.gusi.Lib -don't need WASTE.carbon.lib -don't need any of the Waste (Common) files -don't need libexpat.ppc.Lib -change strdup in parsermodule.c to be (const char*) I build and move this newly created app to /application/Python 2.2.1 just in case there is some weird location problem (though location doesn't seem to make a difference with these errors). I get to the prompt just fine. The first command I try, no matter what command I type generates a "LookupError: no codec search function registered: can't find encoding" Successive simple python syntax like "i= 4" and "print i" generates proper results. When I try to "import cheese" I get the following error "Trackback (most recent call last) File line 1 in ? ImportError: No module named cheese" Stepping through code generates some interesting results. Lets take them one at a time. first error:"LookupError: no codec search function registered: can't find encoding" The PyErr_SetString on line 171 in codecs.c in the function _PyCodec_Lookup appears to get executed, but the error doesn't get displayed until the first commands. Looking through the archives, when there is no Unix encoding, the Mac defaults to MacRoman. I am running under Mac OS X. Can anyone think of a reason why reason why _PyCodec_lookup would be failing in this case. Second Error:"ImportError: No module named cheese" In looking at the code slb files need to be loaded in case_ok. Line 1148 in the file import.c has the only reference to slb files. Putting a break point in case_ok doesn't trip when I try to do my "import cheese". Upon further examination, the stat on line 992 of import.c in the function find_module is failing. I guess I'll take a further look at this one tomorrow. Any insights would be appreciated, though. -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Thursday, June 20, 2002 1:17 PM To: Magladry, Stephen Cc: 'pythonmac-sig@python.org' Subject: Re: [Pythonmac-SIG] error trying to run c extension from carbon Python Stephen, are you extending Python (building a new module to be imported) or embedding Python (putting the whole interpreter into another program)? Some of the things you mention are used for embedding only (calls to PyMac_Initialize and such) but in other places you're referrring to failures to import something. If you're extending Python: you don't need to recompile anything (except your extension module, of course), if you take the standard MacPython binary installer and also select the "developer" option (not selected with the easy install) you should be all set. If you also use distutils to build your extension you should have no problems whatsoever. If you're embedding Python you may not need source either: you just call PyMac_Initialize() and then you can do any call you want. You want to read both the "embedding" section of the standard Python docs and :Mac:Demo:embed.html from the MacPython distribution. On woensdag, juni 19, 2002, at 07:53 , Magladry, Stephen wrote: > I am trying to run a c extension for a build of Python Carbon > and when I try > to import the c extension, I get a "Interpreter not initialized > (version > mismatch?)" error. Here's a run down of what I have done. > > 1. Tried to use stock Carbon Python. It isn't even able to import a new > sample library. It come back with a syntax error, some kind of > stdin error > if I remember correctly. > 2. Needed to modify the Carbon project. As built, It doesn't > support Dynamic > Loading. I added the three options USE_MAC_SHARED_LIBRARIES, > USE_MAC_APPLETE_SUPPORT and HAVE_DYNAMIC_LOADING. > 2.5 Also use the call PYMac_Initialize() instead of PY_Initialize(). > 3. Add the necessary supporting c files in order to get Carbon > Python with > the above library support linking. > 3.5 Use dyload_mac.c in place of dynload_stub.c. > 4. Rebuild PythonCarbonCore using the config.h files as the > above project. > 5. Build a simple c extension that weak links to the newly created > PythonCarbonCore. > 6. Move the new created, PythonCarbonApp, PythonCarbonCore and > myLibrary to > the same folder. > 7. Fire up The Python interpreter. > 8. Enter the command Import myLibrary, with the library file named > "myLibrary.carbon.slb". > 9. Get the error "Interpreter not initialized (version mismatch?)". > > I have stepped through the code at the interpreter level and > the last line > of code that gets executed, at least at the interpreter level is > GetDiskFragment, line 86 in dynload_mac.c. If I try to step > over this line > of code, I get the error. > > Questions: > > 1. Anyone know why I'm getting this error? It doesn't seem like > I have a > version mismatch since everything is running off the same code base. > 2. Does anyone see something glaring that I have done wrong? > 3. Has anyone been able to set up a Python Carbon that is able > to call c > extensions? > 4. Is it even possible in the current state to have the Carbon > code call a c > extensions? > > > Thanks for your time, > > > Stephen Magladry > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 21 10:22:46 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 21 Jun 2002 11:22:46 +0200 Subject: [Pythonmac-SIG] error trying to run c extension from carbon P ython In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE79B@sea-horse.humongous.com> Message-ID: <72F39C46-84F8-11D6-8E3D-0030655234CE@cwi.nl> On Friday, June 21, 2002, at 03:24 , Magladry, Stephen wrote: > Thanks for getting me straighten out. I am able to get my sample c > library, > named cheese, executing in the release build. I need to be able to > build a > slightly stripped down version of Python, though. So I grabbed the > source > archive from the Mac Python Site. I started with the > PythonStandalone.mcp > and made the following changes; Ok, now I see what you're doing. It is possible to build applications this way (the Mac version fo our GRiNS product is done like this), but there are some gotchas. One important one is that you cannot load dynamic modules into a static Python. What happened when you tried this (the "not initialized" error) is that you were actually having *two* Python interpreters in core: the original PythonStandalone-based one, which was initialized, and then your extension module pulled in PythonCoreCarbon, which contained a fresh new interpreter. If you want to go with PythonStandalone you must disable all the dynamic module loading features, as they will lead to the disaster skewtched above, and include all modules you need statically. Add your sourcefiles to your project, put the init routine for your module into macconfig.c and off you go. The other errors you get (about codecs and such) probably all have to do with sys.path not being initialized correctly. This is a procedure of a couple of steps, especially so you can make things like what you want to do work out, but it is a bit convoluted. 1. Get the 'STR ' resource named "PythonPreferencesFileName" (from the application, in your case). 2. If this is a non-empty string it contains the filename of the preferences file (in System Folder:Preferences). This preferences file is opened and put in the resource search list. The steps below will all first look in the preferences file for a resource, and if none is found there they will look in the application. 3. If it is an empty string this signifies there's no preferences file, and all the steps below will only look in the application for preferences. 4. Look for all the preferences ('STR#' 228 and 229 for sys.path, 'alis' 228 and 229 for the Python home folder sys.prefix, 'Popt' 228 and 229 for the startup options. 'GUI' 10240 and 10241 for the GUSI options). For each of these we first look for the 229 resource, which is the "override". If this isn't found we look for the 228 resource (the default). See macgetpath.c and pythonpath.r for the gory details. To see just the end result (i.e. find out what went wrong) option-start your Python, select the "verbose import" and "also failures" options and let Python run. This will tell you where Python is looking for modules. Also, when you have the prompt, print sys.prefix and sys.path. The values here will probably tell you what went wrong. If you want to completely insulate your program from an existing Python installation (what I needed to do for GRiNS) there's a few more tricks you need. Let me know if you need this and I'll try to remember. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 21 10:58:45 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 21 Jun 2002 11:58:45 +0200 Subject: [Pythonmac-SIG] Python embedding in LabVIEW on Mac? (oops, found part of the problem) In-Reply-To: Message-ID: <79D5E008-84FD-11D6-BA5B-0030655234CE@cwi.nl> On Thursday, June 20, 2002, at 11:49 , Marcus H. Mendenhall wrote: > Thanks, Jack. I made some progress, but I will not spend a lot of time > before I get my LabVIEW update. Using PyMac_Initialize results in the > embedded python session working (I can run a dumb script which opens a > file, writes 'hello world' to it, and closes it). However, even if the > interpreter opened no windows (that I can see), LabVIEW 5.0 pops up an > internal error from its window handler and exits as soon as control > returns to LabVIEW from Python. When you say "Python opened no windows" you mean that there's also no Python console window? (the Python console window is just as bothersome to LabVIEW as any other window). To be completely sure that Python (and the underlying GUSI and SIOUX libraries) don't touch any windows you can call PyMac_SetConsoleHandler(PyMac_DummyReadHandler, PyMac_DummyWriteHandler, PyMac_DummyWriteHandler) before calling PyMac_Initialize(). See :Mac:Include:macglue.h for details. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jun 21 14:24:20 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 21 Jun 2002 15:24:20 +0200 Subject: [Pythonmac-SIG] Design question - where should resources go? Message-ID: <31ED83A1-851A-11D6-8310-0030655234CE@cwi.nl> Folks, playing with Bill's wonderful new OSA stuff (btw: are Bill and myself the only two people interested in Interface Builder and such, or is everyone just too busy? In just one week two people announce stuff that allows Python to be used with IB, and nobody else seems interested....) I noticed a problem with MachoPython that I already knew was there, but managed to ignore up until now. The problem is that I don't know where to put various resources (.rsrc files, in other words). Historically, MacPython has been sloppy about where resources were. Some were in the application (although that's mainly to allow them to be overridden with EditPythonPrefs) and most were in PythonCore. Actually, there's some stuff in PythonCore that doesn't really belong there. For example the DLOG resources and such used by EasyDialogs: they've always been in PythonCore, but they really belong in Mac/Lib/EasyDialogs.rsrc (just like all other private resources). For MachoPython i took the quick and dirty approach of stuffing all resources into a Python.rsrc file inside the Python.app application. This is fine if you are using Python.app (or a copy of it) to run your stuff, but breaks in other cases (such as when using Python through Script Editor with Bill's python scripting component). If you attempt to use EasyDialogs it simply won't work (resource not found) and other things also work sub-optimal (i.e. no explanatory strings for MacOS error codes are available). What I'm planning to do is to move the core resources into /Library/Framework/Python.framework, where they belong. What I'm not 100% sure about is the EasyDialogs resources (and similar ones). I'm tempted to put them in their own .rsrc file in the Lib folder. But: this may break things if people expect these resources to be available outside of EasyDialogs. Any ideas on this matter? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From owen@astro.washington.edu Fri Jun 21 16:40:00 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 21 Jun 2002 08:40:00 -0700 Subject: [Pythonmac-SIG] Python and OSA Message-ID: Jack asked (probably rhetorically): "(btw: are Bill and myself the only two people interested in Interface Builder and such, or is everyone just too busy?...)". Interesting question. If I understand correctly, making python a full OSA component means: - It could be used for easily for controlling programs via Apple Events (for instance any application that edits or runs AppleScript would edit or run Python scripts). - Perhaps (based on your reference to IB) Python could be used for programs with native Mac look and feel via InterfaceBuilder. Sounds like a good thing in principal, but not something I'd personally make use of right now. I certainly don't see myself writing Mac-specific anything, as most of my coworkers have moved off of the Mac platform. All my Python work at the moment is in cross-platform GUI programming (in Tkinter, sigh) and in basic utility scripts for text processing and such. I did a lot with AppleScript in the past. I wrote ROFM CGI, a free CGI for serving FileMaker Pro data, and it was painful because of the limitations in AppleScript. Python would have been wonderful. I've toyed with reviving ROFM with Python (now that FMPro has crippled web-serving capabilities in the affordable version), but I understand there's a PHP interface and plan to try that first. -- Russell From smithsm@samuelsmith.org Fri Jun 21 16:55:37 2002 From: smithsm@samuelsmith.org (Samuel Smith) Date: Fri, 21 Jun 2002 09:55:37 -0600 Subject: [Pythonmac-SIG] Design question - where should resources go? In-Reply-To: <31ED83A1-851A-11D6-8310-0030655234CE@cwi.nl> References: <31ED83A1-851A-11D6-8310-0030655234CE@cwi.nl> Message-ID: > > >What I'm planning to do is to move the core resources into >/Library/Framework/Python.framework, where they belong. What I'm not >100% sure about is the EasyDialogs resources (and similar ones). I'm >tempted to put them in their own .rsrc file in the Lib folder. But: >this may break things if people expect these resources to be >available outside of EasyDialogs. > >Any ideas on this matter? Storing the resources in the Lib is a good idea. In the case where the easy dialogs are used to build a python application let build application automatically copy the resources to the new application or package > >-- >- Jack Jansen >http://www.cwi.nl/~jack - >- If I can't dance I don't want to be part of your revolution -- >Emma Goldman - > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ********************************************** Samuel M. Smith Ph.D. 360 W. 920 N. Orem, Utah 84057 801-226-7607 x112 (voice) 801-226-7608 (fax) http://www.samuelsmith.org (web) ********************************************* From jds@wgen.net Fri Jun 21 18:12:43 2002 From: jds@wgen.net (John Stewart) Date: Fri, 21 Jun 2002 13:12:43 -0400 Subject: [Pythonmac-SIG] Embedded: application delivery? Message-ID: Hello, We're working on embedding python as a scripting language within a = shared library for MacOS 8/9. We have the interpreter starting up, and = have managed to kill the console window by editing the prefs. The big question now is this: we need to use various modules = (networking, for example), and need to have the prefs set. What is the = recommended manner for delivery and installation of an application along = with the python libs and modules and pre-set prefs, so that we can use a = single installer? =20 Thanks, jds=20 From stephenm@humongous.com Fri Jun 21 18:21:09 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Fri, 21 Jun 2002 10:21:09 -0700 Subject: [Pythonmac-SIG] error trying to run c extension from carbon P ython Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE79D@sea-horse.humongous.com> Alright, with the information shared with me, found below, the standalone version is not the way to good. It will not jive well with what the code base on the PC side of project is doing. It looks like I'll set up an embedded python with a stub for our initialization. Our PC guys are using http://www.mcmillan-inc.com/install1.html. It packages up all the pyc files and redirects import calls to use this pre-packaged library and is totally free of any other version of Python that may exist on the machine. It looks like macfreeze will at least get me started. Anyone who wants to share their experiences with something think this, their input would be appreciated. I'll start exploring macfreeze and embedding Python. Thanks again for getting me going in the right direction. Stephen Magladry -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@cwi.nl] Sent: Friday, June 21, 2002 2:23 AM To: Magladry, Stephen Cc: 'pythonmac-sig@python.org' Subject: Re: [Pythonmac-SIG] error trying to run c extension from carbon P ython Ok, now I see what you're doing. It is possible to build applications this way (the Mac version fo our GRiNS product is done like this), but there are some gotchas. One important one is that you cannot load dynamic modules into a static Python. From gherman@darwin.in-berlin.de Fri Jun 21 18:50:59 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Fri, 21 Jun 2002 19:50:59 +0200 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! References: Message-ID: <3D136783.3774E0FF@darwin.in-berlin.de> bill fancher wrote: > > > If you want to have a look at this: get http://www.cwi.nl/ftp/jack/python/ > > mac/nibpythonexample.tar.gz, read the README and play away! > > It might be worth dumping the "build" directory from the CurrencyConverter > project since it constitutes the bulk of the download and will be > regenerated by PB. ("Clean" in PB doesn't really make things very clean.) Well, it's just plain superfluous to include the build sub- directory. Even if you clean it in PB, it doesn't go away, but only some of the contents. And, yes, usually it's big. > Haven't really had a chance to get into the code yet, but look forward to > doing so. Thanks to all involved. Nor did I yet, but I'm very interested in it... ;-) Please note that you probably have used PB 2.x which should be only available on OS X 10.2. On my 10.1.5 PB does com- plain, but loads the project. Note that it is very hard to downgrade a project manually to a previous version of PB, so I'd stick to 1.1 unless you really have to use 2.x... Dinu From dan@danshafer.com Fri Jun 21 21:26:12 2002 From: dan@danshafer.com (Dan Shafer) Date: Fri, 21 Jun 2002 13:26:12 -0700 Subject: [Pythonmac-SIG] Python and OSA In-Reply-To: References: Message-ID: Russell E OWen said: At 8:40 AM -0700 6/21/02, Russell E Owen wrote: > All my Python work at the moment is in cross-platform GUI >programming (in Tkinter, sigh) and in basic utility scripts for text >processing and such. You'll probably hear this from more than one source, but check out PythonCard, a cross-platform GUI-based GUI construction kit loosely modeled on HyperCard but on steroids in Python. It runs on OS X (though with a few issues to be resolved yet in details) as well as Win and *nix. http://pythoncard.sourceforge.net. -- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Dan Shafer Technology Visionary - Technology Assessment - Documentation "Looking at technology from every angle" http://www.danshafer.com 831-392-1127 Voice - 831-401-2531 Fax From marcus.h.mendenhall@vanderbilt.edu Fri Jun 21 22:41:59 2002 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Fri, 21 Jun 2002 16:41:59 -0500 Subject: [Pythonmac-SIG] Python and LabVIEW (yet another thought) Message-ID: >On Friday, June 21, 2002, at 03:27 , Marcus H. Mendenhall wrote: >>>To be completely sure that Python (and the underlying GUSI and >>>SIOUX libraries) don't touch any windows you can call >>>PyMac_SetConsoleHandler(PyMac_DummyReadHandler, >>>PyMac_DummyWriteHandler, PyMac_DummyWriteHandler) before calling >>>PyMac_Initialize(). See >> >> OK, I went ahead and looked at the source for the PyMac stuff to see whether this type of solution is feasible. The problem probably arises even earlier in the startup process than setting up the console handlers, since init_common initializes all the Mac toolbox stuff, even in the fully embedded (faceless) case. I may try to dredge up a Mac with a current copy of CW7, and build a custom PythonCore which does no mac UI initialization, and see if this can be made compatible with LabVIEW. If this works, it might not be a bad idea to add some switches so that it is easy to build versions of Python which can be embedded in full-fledged mac apps, which already have a running UI, and are likely to take exception to anyone reinitializing stuff. Basically, what I need is a copy of the unix Python compiled into the form of a Mac shared library, since most of the things I plan to do with it will have no need for Mac interface elements to be accessed from Python. Any thoughts? Marcus From Jack.Jansen@oratrix.com Fri Jun 21 23:00:22 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 22 Jun 2002 00:00:22 +0200 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: <3D136783.3774E0FF@darwin.in-berlin.de> Message-ID: <48BBEA7D-8562-11D6-8DFC-003065517236@oratrix.com> On vrijdag, juni 21, 2002, at 07:50 , Dinu Gherman wrote: >> It might be worth dumping the "build" directory from the >> CurrencyConverter >> project since it constitutes the bulk of the download and will be >> regenerated by PB. ("Clean" in PB doesn't really make things >> very clean.) > > Well, it's just plain superfluous to include the build sub- > directory. Even if you clean it in PB, it doesn't go away, > but only some of the contents. And, yes, usually it's big. So, if I understand correctly there's no way to tell PB to clean up the directory ready for distribution? Sigh... > Please note that you probably have used PB 2.x which should > be only available on OS X 10.2. On my 10.1.5 PB does com- > plain, but loads the project. Note that it is very hard to > downgrade a project manually to a previous version of PB, > so I'd stick to 1.1 unless you really have to use 2.x... No, I haven't installed 10.2 yet. But I did use the April developer tools, and now that I think if it these may be available only to Select members... Silly me, and I think downgrading to the December devtools is difficult... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Fri Jun 21 23:05:38 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 22 Jun 2002 00:05:38 +0200 Subject: [Pythonmac-SIG] Re: Python and LabVIEW (yet another thought) In-Reply-To: Message-ID: <053AE690-8563-11D6-8DFC-003065517236@oratrix.com> On vrijdag, juni 21, 2002, at 11:41 , Marcus H. Mendenhall wrote: >> On Friday, June 21, 2002, at 03:27 , Marcus H. Mendenhall wrote: >>>> To be completely sure that Python (and the underlying GUSI >>>> and SIOUX libraries) don't touch any windows you can call >>>> PyMac_SetConsoleHandler(PyMac_DummyReadHandler, >>>> PyMac_DummyWriteHandler, PyMac_DummyWriteHandler) before >>>> calling PyMac_Initialize(). See >>> >>> > > OK, I went ahead and looked at the source for the PyMac stuff > to see whether this type of solution is feasible. The problem > probably arises even earlier in the startup process than > setting up the console handlers, since init_common initializes > all the Mac toolbox stuff, even in the fully embedded > (faceless) case. This is already possible. Alexandre Parenteau did this for MacCVS, if I'm not mistaken. He's apparently busy right now (otherwise he would probably have jumped in already) but look in the archives (probably around half a year ago). Actually, looking at the code, the only thing init_mac_world() does for Carbon MacPython is call InitCursor(). Could this really be the problem? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Fri Jun 21 23:33:41 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 22 Jun 2002 00:33:41 +0200 Subject: [Pythonmac-SIG] Python and OSA and much more In-Reply-To: Message-ID: On vrijdag, juni 21, 2002, at 05:40 , Russell E Owen wrote: > Jack asked (probably rhetorically): "(btw: are Bill and myself > the only two people interested in Interface Builder and such, > or is everyone just too busy?...)". > > Interesting question. If I understand correctly, making python > a full OSA component means: > - It could be used for easily for controlling programs via > Apple Events (for instance any application that edits or runs > AppleScript would edit or run Python scripts). > - Perhaps (based on your reference to IB) Python could be used > for programs with native > Mac look and feel via InterfaceBuilder. Both correct. And for the second point we now even have two possibilities: we can use either Bill's stuff and connect Python as an OSA language to the AppleScript abilities of IB, or structure it the same way as you would an ObjC or Java application (although that is still in early stages of development). The reason I'm so excited about all this is that we now have all the bits and pieces that I envisioned in my mail of last March (at least: we have proof that these things are possible, code needs to be cleaned up and documentation and samples need to be written), which makes Python the only language on OSX that is feasible for all of unix scripting, CGI programming, OSA scripting, Carbon development and Cocoa development. And as a bonus (in the sense that I wasn't aware of it at the time) we have PythonCard and wxPython too. With all these things built on the Python.framework it is now a question of bundling things right, and picking the balance of providing people with the functionality they need at the click of a button, without immediately overwhelming them with featuritis. What I would like is if the users could download a "Python Control Centre" that would include Python.framework plus some of the packages mentioned above. The Python Control Centre would be able to find out which of the add-on packages are loaded and which aren't, and would know how to load and install those that the user wants (preferably with some outside dependencies too, i.e. if you want to load the Cocoa stuff but you don't have Apple's developer tools installed it would tell you that installing those will make the Cocoa support a lot more powerful, because of IB). Having the devtools installed shouldn't be a prerequisite. Also, you should definitely be able to access documentation for packages you haven't installed yet via the web (and you should probably have the option of downloading selected set of documentation for quick access). Given the current historical packaging the base distribution would probably include the Carbon stuff and the IDE (alongside the shell and CGI scripting stuff and probably Tkinter), while OSA, Cocoa, wxPython and PythonCard would be external. But this distinction should be hidden from the end user, if possible. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From alexp@strata.com Fri Jun 21 23:34:16 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 21 Jun 2002 15:34:16 -0700 Subject: [Pythonmac-SIG] Re: Python and LabVIEW (yet another thought) In-Reply-To: <053AE690-8563-11D6-8DFC-003065517236@oratrix.com> Message-ID: > Actually, looking at the code, the only thing init_mac_world() > does for Carbon MacPython is call InitCursor(). Could this > really be the problem? Not for MacCvs, but we are Carbon only. It could be a bigger problem on Classic to call InitGraf twice. It is right MacCvs initializes Python very early, so probably the multiple calls to InitCursor do not matter. Alex. From andrew.straw@adelaide.edu.au Sat Jun 22 04:17:08 2002 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Sat, 22 Jun 2002 12:47:08 +0930 Subject: [Pythonmac-SIG] porting PyOpenGL to Mac OS X Message-ID: <88F11749-858E-11D6-AE59-00039311EA24@adelaide.edu.au> Hi everyone, I am writing to inquire about the current state of PyOpenGL on Mac OS X. (I am cross-posting this email to both the PyOpenGL devel list and the Python Mac SIG list.) I have been "frozen" on Bob Ippolito's mega-build of Python with PyOpenGL (along with just about everything else) because I need PyOpenGL on Mac OS X, and I have been unable to get it to compile on Mac OS X myself. I am willing to put in some effort to bring the CVS version up to scratch, but I don't want to duplicate effort that others have put in. Has anyone successfully compiled PyOpenGL for Mac OS X since Bob did it in January? If so, I'd love to get a copy of your sources, a diff file, advice, or whatever other help you can offer. I hope some of the recent Python changes (especially the Mac specific ones -- thanks Jack and everyone else!) may make the process smoother, but PyOpenGL is notorious for difficult builds, and I'm certainly no Mac expert. (Cocoa, two level namespaces, and all the rest are way out of my realm of familiarity.) Thanks, Andrew ________________________________________________________ Andrew Straw Ph.D. student -- Department of Physiology, University of Adelaide, Australia Developer -- The Vision Egg -- http://www.visionegg.org/ andrew.straw@adelaide.edu.au ________________________________________________________ From gherman@darwin.in-berlin.de Sat Jun 22 08:53:25 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Sat, 22 Jun 2002 09:53:25 +0200 (CEST) Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: <48BBEA7D-8562-11D6-8DFC-003065517236@oratrix.com> References: <48BBEA7D-8562-11D6-8DFC-003065517236@oratrix.com> Message-ID: <1024732405.3d142cf519a88@webmail.in-berlin.de> Jack Jansen : > > Well, it's just plain superfluous to include the build sub- > > directory. Even if you clean it in PB, it doesn't go away, > > but only some of the contents. And, yes, usually it's big. > > So, if I understand correctly there's no way to tell PB to clean > up the directory ready for distribution? Sigh... AFAIK not in 1.1 at least. But that's not a big deal. I simply use a shell script to collect only the rele- vant pieces in a tarball (or delete the others). Things become much more fun, when using NIB files etc. (actually directories) with CVS, because on SF.net you can't get rid of CVS directories, again... :-/ Dinu From lmeyn@mail.arc.nasa.gov Sun Jun 23 18:30:33 2002 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Sun, 23 Jun 2002 10:30:33 -0700 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: <48BBEA7D-8562-11D6-8DFC-003065517236@oratrix.com> References: <48BBEA7D-8562-11D6-8DFC-003065517236@oratrix.com> Message-ID: At 12:00 AM +0200 6/22/02, Jack Jansen wrote: >No, I haven't installed 10.2 yet. But I did use the April developer >tools, and now that I think if it these may be available only to >Select members... Silly me, and I think downgrading to the December >devtools is difficult... FYI: The April developer tools update, is available to under the free ADC membership too. -- Larry Meyn From Jack.Jansen@oratrix.com Sun Jun 23 22:06:02 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 23 Jun 2002 23:06:02 +0200 Subject: [Pythonmac-SIG] porting PyOpenGL to Mac OS X In-Reply-To: <88F11749-858E-11D6-AE59-00039311EA24@adelaide.edu.au> Message-ID: <06AAA4D5-86ED-11D6-BC79-003065517236@oratrix.com> On zaterdag, juni 22, 2002, at 05:17 , Andrew Straw wrote: > Hi everyone, > > I am writing to inquire about the current state of PyOpenGL on > Mac OS X. (I am cross-posting this email to both the PyOpenGL > devel list and the Python Mac SIG list.) I have it all running, to some extent. The problem is you need a very specific version of Swig to make it work, and even then there's some problems that need fixing: - there are some missing semicolons in .h files! (this, together that no-one from the PyOpenGL developers has yet taken me up on my offer of a patch, makes me wonder about the status of the whole thing) - swig, even with the right version, had trouble with one function so I had to comment it out. - most serious: the output parameter mechanism doesn't get treated right by the version of swig I used, it is somehow an input parameter. All of this is at work, I'll try and remember to attach my patch to the sourceforge bug report I have outstanding tomorrow. Please ping me if it isn't there in another 24 hours. And I'd love to be able to solve the three problems sketched above, too, so if you have time to invest in this that would be great... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Jun 23 22:59:11 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 23 Jun 2002 23:59:11 +0200 Subject: [Pythonmac-SIG] Warning: building MacPython from CVS instable Message-ID: <73041170-86F4-11D6-BC79-003065517236@oratrix.com> Folks, if you're building MacPython from CVS things may be unstable for a couple of days. I'm getting rid of classic builds, (finally) using precompiled headers wherever possible and restructuring the mess of mwerks_foo_config.h files. I'll try to check in bits and pieces only when they're finished, but I'm afraid I can't promise this'll work as I would like it to, so you may want to refrain from cvs updates for a few days. Note that this is only important to people building MacPython with CodeWarrior, MachoPython isn't affected. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From andrew.straw@adelaide.edu.au Mon Jun 24 01:36:18 2002 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Mon, 24 Jun 2002 10:06:18 +0930 Subject: [Pythonmac-SIG] porting PyOpenGL to Mac OS X In-Reply-To: <06AAA4D5-86ED-11D6-BC79-003065517236@oratrix.com> Message-ID: <660AD138-870A-11D6-840D-00039311EA24@adelaide.edu.au> I've got some of PyOpenGL to build on Mac OS X and submitted a patch to the project. This patch only implements extra_link_args, but it fixes enough to get the OpenGL.GL module compiled and working. Swig is a bit much for me, and I read somewhere that everything in the PyOpenGL project uses Swig 1.3a5, so that's what I use. Anyhow, I just had luck building Tkinter, pygame and SDL, and (limited parts of) PyOpenGL from source yesterday, so things are looking good. Incidentally, does anyone have problems with button clicks not being passed through to the app with Tkinter on Mac OS X? For example, if I have a Tkinter.Button, I can click on it with my mouse, it turns blue, but the callback I registered never gets called. I'm planning on investigating this further, but if anyone knows what's going on, it would save me some effort. On Monday, June 24, 2002, at 06:36 AM, Jack Jansen wrote: > > All of this is at work, I'll try and remember to attach my patch to the > sourceforge bug report I have outstanding tomorrow. Please ping me if > it isn't there in another 24 hours. And I'd love to be able to solve > the three problems sketched above, too, so if you have time to invest > in this that would be great... > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > From Jack.Jansen@cwi.nl Mon Jun 24 09:20:08 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 24 Jun 2002 10:20:08 +0200 Subject: [Pythonmac-SIG] porting PyOpenGL to Mac OS X In-Reply-To: <660AD138-870A-11D6-840D-00039311EA24@adelaide.edu.au> Message-ID: <31C55C74-874B-11D6-9AE3-0030655234CE@cwi.nl> On Monday, June 24, 2002, at 02:36 , Andrew Straw wrote: > I've got some of PyOpenGL to build on Mac OS X and submitted a patch to > the project. This patch only implements extra_link_args, but it fixes > enough to get the OpenGL.GL module compiled and working. Swig is a bit > much for me, and I read somewhere that everything in the PyOpenGL > project uses Swig 1.3a5, so that's what I use. Ah, this is useful information! I first tried 1.3.11, this didn't work, then I tried 1.3.9 and this sort-of worked (after some fiddling). I'll see whether I can find 1.3a5 somewhere. Any idea why they would still be using an almost two year old alpha release of swig?? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From jschmitt@ati.com Mon Jun 24 23:57:02 2002 From: jschmitt@ati.com (John Schmitt) Date: Mon, 24 Jun 2002 15:57:02 -0700 Subject: [Pythonmac-SIG] porting PyOpenGL to Mac OS X Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21BD2.7466C710 Content-Type: text/plain; charset="iso-8859-1" Did you guys receive this? Does this answer your question about why they're using the old SWIG? John -----Original Message----- From: Mike C. Fletcher [mailto:mcfletch@rogers.com] Sent: Sunday, June 23, 2002 7:17 PM To: Python List; PyOpenGL Subject: [PyOpenGL] Need for a C (lead) developer... Summary: PyOpenGL (the Python binding to the OpenGL graphics library) is in need of a C developer (preferably with SWIG experience) to work on maintaining and extending the package. Need is both short-term and long-term; we could use an immediate helping hand, but we're also looking for someone interested in long term work. PyOpenGL is a fairly large project (source-size), which is used by a considerable number of people (latest version has been downloaded something like 16,000 times). Developers looking to take on a popular project and make a name for themselves would find this a good opportunity. Current Tasks: PyOpenGL is currently generated using an old version of the SWIG wrapper generator (originally chosen because of missing features in other versions of SWIG with the idea that the missing features would eventually be adopted in newer SWIG versions (status of this unknown, but some work is definitely required to use the newer versions)). This build process tends to create lots of problems for those porting to new architectures, and we'd like to move off the (old, beta) version soon. This is a fairly extensive project, and will require familiarising yourself with the code base before making the attempt. We have a number of cross-platform build issues that need to be coordinated and integrated. In one case, we have already-submitted patches/fixes for fixing bug(s), in others, there are patches not yet submitted, but available. We need these integrated and tested. Integration is the developer requirement, we can get users with the exotic architectures to test the fixed versions. We have reports of complete meltdown under OpenGL 1.3 implementations under Linux. This is likely a trivial build or configuration problem, but it needs to be tracked down. Future Tasks: Maintenance of the package. Creation of new wrappers for common OpenGL modules (optional). Simplification of the build system for exotic architectures. Insert your PyOpenGL dreams here. Resources: The project has 3 administrators, myself (a designer with minimal (read non-existent) C coding skills), Tarn (author of the current code (current missing in action)) and Rene (who is/was primarily interested in the building and porting work). I work primarily on the OpenGLContext side (which provides a series of tests for the base implementation, and tends to uncover errors as I develop it). I tend to do the work on the web-site, and general answering of questions when I can. At the moment, we have no active C developers, and just myself working on the administrative front. The PyOpenGL work I'm doing is minimal due to other projects and the fact that I'm largely unqualified for the work that needs to be done. I am working on a way to use fonttools for rendering 3D text in PyOpenGL+OpenGLContext, but that's not going to help with the general coding that needs to get done. How to Get Involved: If you'd be interested in working as a developer, let me know and I'll see about adding you to the developer list. People familiar with the PyOpenGL codebase and project would be especially welcome. http://pyopengl.sourceforge.net/ With thanks, Mike Fletcher _______________________________________ Mike C. Fletcher http://members.rogers.com/mcfletch/ -- http://mail.python.org/mailman/listinfo/python-list ------_=_NextPart_001_01C21BD2.7466C710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Pythonmac-SIG] porting PyOpenGL to Mac OS X

Did you guys receive this?  Does this answer = your question about why they're using the old SWIG?

John

-----Original Message-----
From: Mike C. Fletcher [mailto:mcfletch@rogers.com]
Sent: Sunday, June 23, 2002 7:17 PM
To: Python List; PyOpenGL
Subject: [PyOpenGL] Need for a C (lead) = developer...


Summary:
        PyOpenGL = (the Python binding to the OpenGL graphics library) is in need
of a C developer (preferably with SWIG experience) = to work on
maintaining and extending the package.  Need is = both short-term and
long-term; we could use an immediate helping hand, = but we're also
looking for someone interested in long term = work.

        PyOpenGL = is a fairly large project (source-size), which is used by a
considerable number of people (latest version has = been downloaded
something like 16,000 times).  Developers = looking to take on a popular
project and make a name for themselves would find = this a good opportunity.


Current Tasks:
        PyOpenGL = is currently generated using an old version of the SWIG wrapper
generator (originally chosen because of missing = features in other
versions of SWIG with the idea that the missing = features would
eventually be adopted in newer SWIG versions (status = of this unknown,
but some work is definitely required to use the = newer versions)).  This
build process tends to create lots of problems for = those porting to new
architectures, and we'd like to move off the (old, = beta) version soon.
This is a fairly extensive project, and will require = familiarising
yourself with the code base before making the = attempt.

        We have a = number of cross-platform build issues that need to be
coordinated and integrated.  In one case, we = have already-submitted
patches/fixes for fixing bug(s), in others, there = are patches not yet
submitted, but available.  We need these = integrated and tested.
Integration is the developer requirement, we can get = users with the
exotic architectures to test the fixed = versions.

        We have = reports of complete meltdown under OpenGL 1.3 implementations
under Linux.  This is likely a trivial build or = configuration problem,
but it needs to be tracked down.


Future Tasks:
        Maintenance of the package.

        Creation = of new wrappers for common OpenGL modules (optional).

        Simplification of the build system for exotic = architectures.

        Insert = your PyOpenGL dreams here.


Resources:
        The = project has 3 administrators, myself (a designer with minimal (read =
non-existent) C coding skills), Tarn (author of the = current code
(current missing in action)) and Rene (who is/was = primarily interested
in the building and porting work).  I work = primarily on the
OpenGLContext side (which provides a series of tests = for the base
implementation, and tends to uncover errors as I = develop it).  I tend to
do the work on the web-site, and general answering = of questions when I can.

        At the = moment, we have no active C developers, and just myself working on =
the administrative front.  The PyOpenGL work = I'm doing is minimal due to
other projects and the fact that I'm largely = unqualified for the work
that needs to be done.  I am working on a way = to use fonttools for
rendering 3D text in PyOpenGL+OpenGLContext, but = that's not going to
help with the general coding that needs to get = done.


How to Get Involved:
        If you'd = be interested in working as a developer, let me know and I'll
see about adding you to the developer list. People = familiar with the
PyOpenGL codebase and project would be especially = welcome.

        http://pyopengl.sourceforge.net/

With thanks,
Mike Fletcher

_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/




--
http://mail.python.org/mailman/listinfo/python-list

------_=_NextPart_001_01C21BD2.7466C710-- From sdm7g@mac.com Wed Jun 26 17:07:20 2002 From: sdm7g@mac.com (Steven Majewski) Date: Wed, 26 Jun 2002 12:07:20 -0400 (EDT) Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: Message-ID: Added Bill Bumgarner to Cc: On Wed, 19 Jun 2002, Jack Jansen wrote: > Folks, > we've just succeeded in creating the first Python applet (we > think, you can never be sure about the "first" bit:-) that is > awakened from a NIB file built with Interface Builder. > > The code is all pretty messy (both the Python code and the ObjC > code), but at least it seems to work. > > If you want to have a look at this: get > http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz, > read the README and play away! > > If had very limited success (none, actually) reaching the pyobjc > crowd the last few weeks, so I suggest that discussion of this > beast take place on pythonmac-sig@python.org with a cc to Pyobjc- > dev@lists.sourceforge.net, for the time being. Jack, I'm still here and very interested! I finally quit my job at UVA, and I've just gotten around to switching my email subscriptions to another account ( either sdm7g@mac.com or majewss@cstone.net ) and getting it hooked up to OSX's mail client ( as well as moving lots of work onto my personal laptop from my former office machines ). I'm taking some time off -- I'm about to leave to go camping at the beach with my two boys. When I get back (besides job hunting) I'm going to get back into macpython and pyobjc in a major way -- I should have a bit more time to hack on it. CC: to bbum -- Bill's the email admin. on the pyobjc mailing list -- Bill: if you don't have time to handle it you could transfer it to me. But maybe because the list has been so quit, he just hasn't looked it the inbox for a while. ( alternatives: just make the list open ? or now that it's getting more mailstream for macpython, just switch to macpython list ? ) I'll excitedly try out all this stuff as soon as I get back from the beach! -- Steve From bbum@codefab.com Wed Jun 26 17:32:55 2002 From: bbum@codefab.com (Bill Bumgarner) Date: Wed, 26 Jun 2002 12:32:55 -0400 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: Message-ID: <5E4CDEE4-8922-11D6-9E1B-000393877AE4@codefab.com> I believe there is value in keeping the NIB/ObjC discussion on pyobjc simply because the discussion is so specific to a particular aspect of a very particular platform. But, whatever, I have almost zero time to devote to this stuff right now and, as such... Tag! Steve! You're it! I am embarrassed to admit that I currently have *no idea* what the admin password is to the pyobjc mailing list. I will ping the SF administrators and see what can be done -- when it is resolved, Steve can take admin. b.bum On Wednesday, June 26, 2002, at 12:07 PM, Steven Majewski wrote: > > Added Bill Bumgarner to Cc: > > On Wed, 19 Jun 2002, Jack Jansen wrote: > >> Folks, >> we've just succeeded in creating the first Python applet (we >> think, you can never be sure about the "first" bit:-) that is >> awakened from a NIB file built with Interface Builder. >> >> The code is all pretty messy (both the Python code and the ObjC >> code), but at least it seems to work. >> >> If you want to have a look at this: get >> http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz, >> read the README and play away! >> >> If had very limited success (none, actually) reaching the pyobjc >> crowd the last few weeks, so I suggest that discussion of this >> beast take place on pythonmac-sig@python.org with a cc to Pyobjc- >> dev@lists.sourceforge.net, for the time being. > > Jack, > > I'm still here and very interested! > > I finally quit my job at UVA, and I've just gotten around to switching > my email subscriptions to another account ( either sdm7g@mac.com or > majewss@cstone.net ) and getting it hooked up to OSX's mail client > ( as well as moving lots of work onto my personal laptop from my > former office machines ). > > I'm taking some time off -- I'm about to leave to go camping at the > beach with my two boys. When I get back (besides job hunting) I'm > going to get back into macpython and pyobjc in a major way -- I should > have a bit more time to hack on it. > > CC: to bbum -- Bill's the email admin. on the pyobjc mailing list -- > Bill: if you don't have time to handle it you could transfer it to me. > But maybe because the list has been so quit, he just hasn't looked it > the inbox for a while. ( alternatives: just make the list open ? or > now that it's getting more mailstream for macpython, just switch to > macpython list ? ) > > I'll excitedly try out all this stuff as soon as I get back from the > beach! > > -- Steve > > > > b.bum ....lying there snoring, breath smelling like a 1948 buick. From pdetagyos@palm.com Wed Jun 26 18:20:49 2002 From: pdetagyos@palm.com (pdetagyos@palm.com) Date: Wed, 26 Jun 2002 17:20:49 +0000 (GMT) Subject: [Pythonmac-SIG] IDLE Problem on MachoPython with native Aqua Tkinter Message-ID: <20020626172049.59B484515@mo110uhou.palm.net> I finally got python built and installed with native Aqua Tkinter (Thank You Tony Lownds!!), and am now playing around with IDLE. All looks to be well, until I start editing some code. In the IDLE shell, I import a library (say, Tkinter). Then, I type the following: f = Tkinter.Frame( As soon as I hit the (, the pop-up tip window appears. The problem is, when this tip window appears, it gets the focus, and I can't type in the shell window anymore. This is more than a little annoying. Please tell me that there is some way to get around this behavior. Is there a workaround that still allows the tooltips to be shown, but have the shell window retain the input focus? Thanks in advance. Peter From tony@lownds.com Wed Jun 26 19:42:49 2002 From: tony@lownds.com (Tony Lownds) Date: Wed, 26 Jun 2002 11:42:49 -0700 Subject: [Pythonmac-SIG] IDLE Problem on MachoPython with native Aqua Tkinter In-Reply-To: <20020626172049.59B484515@mo110uhou.palm.net> References: <20020626172049.59B484515@mo110uhou.palm.net> Message-ID: > >Please tell me that there is some way to get around this behavior. >Is there a workaround that still allows the tooltips to be shown, >but have the shell window retain the input focus? Annoying isn't it? A workaround is possible, but I have not not finished a patch to IDLE. MacTk has long had an undocumented command to change the "window style". For instance, ::tk::unsupported::MacWindowStyle style $top floating sideTitleproc Jim Ingham graciously and recently added a "help" window style to Tk CVS. That should make the tooltips work beautifully. So, if you do a CVS checkout and build of Tcl/Tk, and patch IDLE like Tools/idle/ToolTip.py line 46 or so: tw.wm_overrideredirect(1) tw.wm_geometry("+%d+%d" % (x, y)) + # need a good "if" statement + tw.tk.call("::tk::unsupported::MacWindowStyle", "style", + tw._w, "side", "none") self.showcontents() It should fix that problem. -Tony From skim@adobe.com Thu Jun 27 01:59:18 2002 From: skim@adobe.com (Sung H. Kim) Date: Wed, 26 Jun 2002 17:59:18 -0700 Subject: [Pythonmac-SIG] Imported carbon C lib not allowed if using Tkinter? Message-ID: I have a Python extension question. Python script imports a C library (a carbonized lib), and that python script also uses Tkinter. Not allowed? Thank you. --Sung H. Kim From Jack.Jansen@oratrix.com Thu Jun 27 11:19:10 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 27 Jun 2002 12:19:10 +0200 Subject: [Pythonmac-SIG] Imported carbon C lib not allowed if using Tkinter? In-Reply-To: Message-ID: <525B62C9-89B7-11D6-895A-003065517236@oratrix.com> On donderdag, juni 27, 2002, at 02:59 , Sung H. Kim wrote: > I have a Python extension question. > > Python script imports a C library (a carbonized lib), and that > python script also uses Tkinter. Not allowed? Thank you. This is indeed not possible, unfortunately. Tkinter does not work under the Carbon model on OS9. I've spent weeks on a solution but didn't find any, so I think it's a lost cause. Your best bet is probably to see if the library you need is available under OSX and move there. Python on OSX (not MacPython but the normal distribution, also known as MachoPython on this mailing list) works reasonably well with Aqua Tk. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dan@grassi.org Fri Jun 28 02:04:45 2002 From: dan@grassi.org (Dan Grassi) Date: Thu, 27 Jun 2002 21:04:45 -0400 Subject: [Pythonmac-SIG] Embedded Python In-Reply-To: Message-ID: <08E24A77-8A33-11D6-9FB7-00039346A28A@grassi.org> Concerning embedded python take a look at http://www.boost.org/libs/python/doc/index.html Note: GCC 3.0.4 under Cygwin and RedHat Linux 7.1. All tests pass. This looks like a project that Mac OS X support could be added to instead or re-inventing the embedded python wheel. Dan From dan@grassi.org Sat Jun 29 01:36:26 2002 From: dan@grassi.org (Dan Grassi) Date: Fri, 28 Jun 2002 20:36:26 -0400 Subject: [Pythonmac-SIG] Python.org and Mac In-Reply-To: <08E24A77-8A33-11D6-9FB7-00039346A28A@grassi.org> Message-ID: <3EA1D53B-8AF8-11D6-82E8-00039346A28A@grassi.org> I was just looking at python.org and it is a little confusing for the mac. On the main page there is a link for "Macintosh" that links to: http://python.org/download/download_mac.html and this page has no link to the mac page that actually has the downloads at: http://python.org/2.2.1/mac.html Further the actual downloads page at: http://python.org/2.2.1/mac.html has no mention of the Fink installer. It might be best if the main page "Macintosh" link were removed and the http://python.org/2.2.1/mac.html page had a link to the Fink installer for OSX. Or at least place a link on http://python.org/download/download_mac.html to http://python.org/2.2.1/mac.html Dan From dan@gui.com Sat Jun 29 01:42:38 2002 From: dan@gui.com (Dan Shafer) Date: Fri, 28 Jun 2002 17:42:38 -0700 Subject: [Pythonmac-SIG] Tk on OS 9? Message-ID: Ok, I may have to drop back to OS 9 from OS X to create an app for a client. What is the state/viability of Tk on Classic? And are there any GUI IDE kinds of tools other than the one that comes with Python on OS 9 from Just that I should check out? Any other big red flags or cautions? -- Dan Shafer, Product Development Expert Helping you turn your best ideas into products that sell http://www.danshafer.com From altis@semi-retired.com Sat Jun 29 01:53:11 2002 From: altis@semi-retired.com (Kevin Altis) Date: Fri, 28 Jun 2002 17:53:11 -0700 Subject: [Pythonmac-SIG] Python.org and Mac In-Reply-To: <3EA1D53B-8AF8-11D6-82E8-00039346A28A@grassi.org> Message-ID: To further confuse issues, some people have been using the 2.2.x disk images posted at: http://sourceforge.net/project/showfiles.php?group_id=10718 current one is MachoPython-2.2.1-3.dmg This is a framework build and designed to be used with wxPython Mac previews. Is it the same as builds Jack has been making? I don't know. Is it the same as the MachoPython Apple will be distributing with Jaguar? I don't know. So, more confusion. If there are going to be a lot of different distributions of MachoPython on Mac OS X it would be nice to know what the differences are, whether it is going to matter for users or people developing other packages for use on the Mac and so on. The Mac is not my primary platform so I'm without a clue, I just go with the disk images I know work. ka > -----Original Message----- > From: pythonmac-sig-admin@python.org > [mailto:pythonmac-sig-admin@python.org]On Behalf Of Dan Grassi > Sent: Friday, June 28, 2002 5:36 PM > To: Pythonmac-sig@python.org > Subject: [Pythonmac-SIG] Python.org and Mac > > > I was just looking at python.org and it is a little confusing for the > mac. On the main page there is a link for "Macintosh" that links to: > http://python.org/download/download_mac.html > and this page has no link to the mac page that actually has the > downloads at: > http://python.org/2.2.1/mac.html > > Further the actual downloads page at: > http://python.org/2.2.1/mac.html > has no mention of the Fink installer. > > > It might be best if the main page "Macintosh" link were removed and the > http://python.org/2.2.1/mac.html > page had a link to the Fink installer for OSX. > > Or at least place a link on > http://python.org/download/download_mac.html > to > http://python.org/2.2.1/mac.html > > Dan From dan@grassi.org Sat Jun 29 02:37:57 2002 From: dan@grassi.org (Dan Grassi) Date: Fri, 28 Jun 2002 21:37:57 -0400 Subject: [Pythonmac-SIG] Bug in list + tupple? In-Reply-To: Message-ID: I noticed that "a=a+b" is not the same as "a+=b" if a is a list and b is a tuple. See the code below. I have tested this on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha. Is this correct behavior? It seems intuitively wrong to me. a=[1] b=(2,) print 1,type(a), a print 1,type(b), b c=a+b print 2,type(a), a print 2,type(b), b a=a+b print 3,type(a), a print 3,type(b), b a+=b print 4,type(a), a print 4,type(b), b When I run this program I get: >>> >>> a=[1] >>> b=(2,) >>> >>> print 1,type(a), a 1 [1] >>> print 1,type(b), b 1 (2,) >>> c=a+b Traceback (most recent call last): File "", line 1, in ? TypeError: can only concatenate list (not "tuple") to list >>> >>> print 2,type(a), a 2 [1] >>> print 2,type(b), b 2 (2,) >>> a=a+b Traceback (most recent call last): File "", line 1, in ? TypeError: can only concatenate list (not "tuple") to list >>> >>> print 3,type(a), a 3 [1] >>> print 3,type(b), b 3 (2,) >>> a+=b >>> >>> print 4,type(a), a 4 [1, 2] >>> print 4,type(b), b 4 (2,) >>> Dan From dan@brotsky.com Sat Jun 29 10:42:38 2002 From: dan@brotsky.com (Dan Brotsky) Date: Sat, 29 Jun 2002 02:42:38 -0700 Subject: [Pythonmac-SIG] newbie process question about building MachoPython Message-ID: <8C4F820E-8B44-11D6-8DFA-0003931036B4@brotsky.com> (Please forgive me if the answer to this question should have been obvious: I'm quite new to building the CVS tree from scratch.) I've been having trouble building MachoPython CVS head on OS 10.1.5 (latest released devtools). I use the fink environment for most of my unixy stuff, and so set CPPFLAGS to -I/sw/include and LDFLAGS to -L/sw/lib. Building has been giving errors linking the Parser module (can't find library dl) and also compiling some other modules (can't find header dl). I believe I've found the two problems in Makefile.pre.in underlying the failures-- 1. The PGEN build line doesn't add $(LDFLAGS) 2. The CPPFLAGS and CFLAGS defines don't include @CPPFLAGS@ and @CFLAGS@. --and I've prepared a context-diff patch that fixes those problems. So now comes the process question: 1. Should I submit a bug in sourceforge? 2. Should I submit the patch in sourceforge? I know that the python.org culture page says the answers to 1 and 2 are yes, but I wanted to check first given that this is kind of a Mac-y thing rather than a general thing. Thanks in advance for gentle responses. dan From dev@brotsky.com Sat Jun 29 10:43:29 2002 From: dev@brotsky.com (Daniel Brotsky) Date: Sat, 29 Jun 2002 02:43:29 -0700 Subject: [Pythonmac-SIG] newbie process question about building MachoPython Message-ID: (Please forgive me if the answer to this question should have been obvious: I'm quite new to building the CVS tree from scratch.) I've been having trouble building MachoPython CVS head on OS 10.1.5 (latest released devtools). I use the fink environment for most of my unixy stuff, and so set CPPFLAGS to -I/sw/include and LDFLAGS to -L/sw/lib. Building has been giving errors linking the Parser module (can't find library dl) and also compiling some other modules (can't find header dl). I believe I've found the two problems in Makefile.pre.in underlying the failures-- 1. The PGEN build line doesn't add $(LDFLAGS) 2. The CPPFLAGS and CFLAGS defines don't include @CPPFLAGS@ and @CFLAGS@. --and I've prepared a context-diff patch that fixes those problems. So now comes the process question: 1. Should I submit a bug in sourceforge? 2. Should I submit the patch in sourceforge? I know that the python.org culture page says the answers to 1 and 2 are yes, but I wanted to check first given that this is kind of a Mac-y thing rather than a general thing. Thanks in advance for gentle responses. dan From dev@brotsky.com Sat Jun 29 20:11:27 2002 From: dev@brotsky.com (Daniel Brotsky) Date: Sat, 29 Jun 2002 12:11:27 -0700 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: Message-ID: <032BBB55-8B94-11D6-8DFA-0003931036B4@brotsky.com> On Tuesday, June 18, 2002, at 03:07 PM, Jack Jansen wrote: > If you want to have a look at this: get > http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz, read the > README and play away! I've finally gotten this working. Very cool, Jack (et al), thanks! I thought the following experiences I had building and running all of this might help others who are trying: 1. I had problems building MachoPython under Mac OS X with a fink-based environment; I've reported those separately. 2. The README in dist/src/Mac/OSX/ fails to mention the make target installunixprograms (which is very handy), and the README in the nibexample directory mistakenly calls it installunixcommands. 3. Doing make installmacsubtree in Mac/OSX/ doesn't actually install the "Mac/scripts" directory that the nib example's buildpyapp.sh relies on. (It only installs the lib and lib-scriptpackages dirs.) This has to be done manually. (Perhaps installmacsubtree should install the scripts dir?) 4. There is a very handy Mac/OSX/ make target symlinkmacsubtree which is not documented in the README file. This target does install the Mac/scripts directory (via the symlink) and I suspect it's what Jack uses, but it fails if it's run after installmacsubtree (because the symlink would replace the actual directory). 5. Someone else has already mentioned that Jack used the beta projectbuilder to build the objc stuff; I also found that it worked fine just to use the released one. I'm happy to help update the Mac/OSX documentation, etc., but (as outlined in my process question earlier) I'm not quite sure how to go about it. All suggestions welcome. dan From Jack.Jansen@oratrix.com Sat Jun 29 23:47:39 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 30 Jun 2002 00:47:39 +0200 Subject: [Pythonmac-SIG] Bug in list + tupple? In-Reply-To: Message-ID: <36AB3548-8BB2-11D6-AF0F-003065517236@oratrix.com> I'm not sure it's a bug, but it's definitely anti-intuitive. Apparently the += operator on lists is happy with any RHS that is a sequence while the + operator (from the list LHS) requires a list RHS. I suggest you submit a bug report. If there is a good reason for the difference it should at least be clearly documented. On zaterdag, juni 29, 2002, at 03:37 , Dan Grassi wrote: > I noticed that "a=a+b" is not the same as "a+=b" if a is a list > and b is a tuple. See the code below. > > I have tested this on 2.2.1 MacPython, 2.2 MachoPython and 2.2 > Python on an Alpha. > > Is this correct behavior? It seems intuitively wrong to me. > > a=[1] > b=(2,) > > print 1,type(a), a > print 1,type(b), b > c=a+b > > print 2,type(a), a > print 2,type(b), b > a=a+b > > print 3,type(a), a > print 3,type(b), b > a+=b > > print 4,type(a), a > print 4,type(b), b > > When I run this program I get: > > >>> > >>> a=[1] > >>> b=(2,) > >>> > >>> print 1,type(a), a > 1 [1] > >>> print 1,type(b), b > 1 (2,) > >>> c=a+b > Traceback (most recent call last): > File "", line 1, in ? > TypeError: can only concatenate list (not "tuple") to list > >>> > >>> print 2,type(a), a > 2 [1] > >>> print 2,type(b), b > 2 (2,) > >>> a=a+b > Traceback (most recent call last): > File "", line 1, in ? > TypeError: can only concatenate list (not "tuple") to list > >>> > >>> print 3,type(a), a > 3 [1] > >>> print 3,type(b), b > 3 (2,) > >>> a+=b > >>> > >>> print 4,type(a), a > 4 [1, 2] > >>> print 4,type(b), b > 4 (2,) > >>> > > Dan > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Jun 29 23:54:09 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 30 Jun 2002 00:54:09 +0200 Subject: [Pythonmac-SIG] newbie process question about building MachoPython In-Reply-To: <8C4F820E-8B44-11D6-8DFA-0003931036B4@brotsky.com> Message-ID: <1F9A68CB-8BB3-11D6-AF0F-003065517236@oratrix.com> My guess (because of the references to "dl") is that you're picking up stuff from /sw that you don't want to pick up. Or, at least, you're picking up stuff that the build process hasn't been tested for. Specifically, if you have dl installed in /sw (dl is the "linux-way" of doing dynamic loading) it could be that Python partially configures itself to use dl-based dynamic linking in stead of dynload-based dynamic linking. But: apparently it only partially works (otherwise it would have "just worked"). The last sentence because I know some people have used dl on OSX and gotten it to work (IIRC). My suggestion would be to not use /sw/include and /sw/lib unconditionally but in stead refer to it with the various --with-foobar options of configure (for all foobars you have in /sw). On zaterdag, juni 29, 2002, at 11:42 , Dan Brotsky wrote: > (Please forgive me if the answer to this question should have > been obvious: I'm quite new to building the CVS tree from > scratch.) > > I've been having trouble building MachoPython CVS head on OS > 10.1.5 (latest released devtools). I use the fink environment > for most of my unixy stuff, and so set CPPFLAGS to > -I/sw/include and LDFLAGS to -L/sw/lib. Building has been > giving errors linking the Parser module (can't find library dl) > and also compiling some other modules (can't find header > dl). I believe I've found the two problems in > Makefile.pre.in underlying the failures-- > > 1. The PGEN build line doesn't add $(LDFLAGS) > > 2. The CPPFLAGS and CFLAGS defines don't include @CPPFLAGS@ and > @CFLAGS@. > > --and I've prepared a context-diff patch that fixes those problems. > > So now comes the process question: > > 1. Should I submit a bug in sourceforge? > > 2. Should I submit the patch in sourceforge? > > I know that the python.org culture page says the answers to 1 > and 2 are yes, but I wanted to check first given that this is > kind of a Mac-y thing rather than a general thing. > > Thanks in advance for gentle responses. > > dan > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Jun 30 00:02:54 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 30 Jun 2002 01:02:54 +0200 Subject: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: <032BBB55-8B94-11D6-8DFA-0003931036B4@brotsky.com> Message-ID: <5824AFA2-8BB4-11D6-AF0F-003065517236@oratrix.com> On zaterdag, juni 29, 2002, at 09:11 , Daniel Brotsky wrote: > 1. I had problems building MachoPython under Mac OS X with a > fink-based environment; I've reported those separately. I replied to those separately. > 2. The README in dist/src/Mac/OSX/ fails to mention the make > target installunixprograms (which is very handy), and the > README in the nibexample directory mistakenly calls it > installunixcommands. Thanks, I'll add it. > > 3. Doing make installmacsubtree in Mac/OSX/ doesn't actually > install the "Mac/scripts" directory that the nib example's > buildpyapp.sh relies on. (It only installs the lib and > lib-scriptpackages dirs.) This has to be done manually. > (Perhaps installmacsubtree should install the scripts dir?) My mistake. And I didn't notice because I've used symlinkmacsubtree:-) > 4. There is a very handy Mac/OSX/ make target symlinkmacsubtree > which is not documented in the README file. This target does > install the Mac/scripts directory (via the symlink) and I > suspect it's what Jack uses, but it fails if it's run after > installmacsubtree (because the symlink would replace the actual > directory). It was really a hack for myself that escaped, and now is used by other things:-) However: I want to get rid of it. I think that if you want to run from the development tree you should use a .pth file in site-python to do this magic (a trick shown me by someone here). But: that still leaves the scripts from Mac/scripts with nowhere to go. I guess this all shows that it's now time to really bite the bullet and get rid of most of the whole Mac/ subtree, distributing the stuff where it belongs (i.e. Mac/Lib should go to Lib/plat-mac, Mac/Scripts to Scripts/mac, etc). I'll bring it up on python-dev. > > I'm happy to help update the Mac/OSX documentation, etc., but > (as outlined in my process question earlier) I'm not quite sure > how to go about it. All suggestions welcome. What I would like most is some user-centered documentation. But for that we first need a clear idea of what the "standard" Python on OSX is going to look like, and as has been pointed out in a couple of other messages here over the last few days that's really unclear... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Jun 30 00:06:38 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 30 Jun 2002 01:06:38 +0200 Subject: [Pythonmac-SIG] Tk on OS 9? In-Reply-To: Message-ID: On zaterdag, juni 29, 2002, at 02:42 , Dan Shafer wrote: > Ok, I may have to drop back to OS 9 from OS X to create an app > for a client. What is the state/viability of Tk on Classic? And > are there any GUI IDE kinds of tools other than the one that > comes with Python on OS 9 from Just that I should check out? I wouldn't touch OS9 Tkinter with a ten foot pole, especially not if it's for a client. OS9 Tk development has halted, and non-Carbon MacPython development has halted. And the people with the know-how are all very busy with OSX Tk and Python:-) I heard that OS9 wxPython still had someone working on it, does anyone know how far this is, and whether it'll continue to live for a while longer? But what might be the most sensible thing to do is convince your client that life will be a lot simpler if he moves to OSX... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Robert.van.Liere@cwi.nl Sun Jun 30 06:32:32 2002 From: Robert.van.Liere@cwi.nl (Robert.van.Liere@cwi.nl) Date: Sun, 30 Jun 2002 07:32:32 +0200 (MEST) Subject: [Pythonmac-SIG] Bob is outta here!! Message-ID: Sorry to bore you with this message, but I am out of the office until 8 July 2002 For urgent matters, please contact one of the following: - CWI Marja Hegt (Marja.Hegt@cwi.nl) - VR Jurriaan Mulder (mullie@cwi.nl) I may occasionally be reading mail and might even reply, but don't count on it! In any case I will get back to you ASAP. Thanks, -- Robert van Liere