pyobjc-dev Mailing List for PyObjC (Page 299)
Brought to you by:
ronaldoussoren
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(30) |
May
(18) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
|
Sep
(23) |
Oct
(180) |
Nov
(291) |
Dec
(95) |
2003 |
Jan
(338) |
Feb
(352) |
Mar
(97) |
Apr
(46) |
May
(226) |
Jun
(184) |
Jul
(145) |
Aug
(141) |
Sep
(69) |
Oct
(161) |
Nov
(96) |
Dec
(90) |
2004 |
Jan
(66) |
Feb
(87) |
Mar
(98) |
Apr
(132) |
May
(115) |
Jun
(68) |
Jul
(150) |
Aug
(92) |
Sep
(59) |
Oct
(52) |
Nov
(17) |
Dec
(75) |
2005 |
Jan
(84) |
Feb
(191) |
Mar
(133) |
Apr
(114) |
May
(158) |
Jun
(185) |
Jul
(62) |
Aug
(28) |
Sep
(36) |
Oct
(88) |
Nov
(65) |
Dec
(43) |
2006 |
Jan
(85) |
Feb
(62) |
Mar
(92) |
Apr
(75) |
May
(68) |
Jun
(101) |
Jul
(73) |
Aug
(37) |
Sep
(91) |
Oct
(65) |
Nov
(30) |
Dec
(39) |
2007 |
Jan
(24) |
Feb
(28) |
Mar
(10) |
Apr
(2) |
May
(18) |
Jun
(16) |
Jul
(21) |
Aug
(6) |
Sep
(30) |
Oct
(31) |
Nov
(153) |
Dec
(31) |
2008 |
Jan
(63) |
Feb
(70) |
Mar
(47) |
Apr
(24) |
May
(59) |
Jun
(22) |
Jul
(12) |
Aug
(7) |
Sep
(14) |
Oct
(26) |
Nov
(5) |
Dec
(5) |
2009 |
Jan
(10) |
Feb
(41) |
Mar
(70) |
Apr
(88) |
May
(49) |
Jun
(62) |
Jul
(34) |
Aug
(15) |
Sep
(55) |
Oct
(40) |
Nov
(67) |
Dec
(21) |
2010 |
Jan
(60) |
Feb
(17) |
Mar
(26) |
Apr
(26) |
May
(29) |
Jun
(4) |
Jul
(21) |
Aug
(21) |
Sep
(10) |
Oct
(12) |
Nov
(3) |
Dec
(19) |
2011 |
Jan
(3) |
Feb
(13) |
Mar
(8) |
Apr
(8) |
May
(17) |
Jun
(20) |
Jul
(21) |
Aug
(7) |
Sep
|
Oct
|
Nov
(9) |
Dec
(11) |
2012 |
Jan
(3) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
(14) |
Jul
(5) |
Aug
(2) |
Sep
(15) |
Oct
(2) |
Nov
(23) |
Dec
(1) |
2013 |
Jan
(8) |
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
(12) |
Nov
(10) |
Dec
(3) |
2014 |
Jan
(7) |
Feb
(14) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(11) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(1) |
Dec
(2) |
2015 |
Jan
(9) |
Feb
(7) |
Mar
(1) |
Apr
|
May
(7) |
Jun
|
Jul
(5) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
2016 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(21) |
Oct
(17) |
Nov
|
Dec
(36) |
2017 |
Jan
(6) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
2018 |
Jan
(2) |
Feb
(3) |
Mar
(3) |
Apr
(14) |
May
(2) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(6) |
Oct
(16) |
Nov
(1) |
Dec
(6) |
2019 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2025 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <bb...@ma...> - 2002-10-16 15:35:01
|
(Jack; thanks for the CC to pyobjc. I have now subscribed to pythonmac and will try to keep up with things in this SIG.) First, a brief update on the progress made on the PyObjC project. The module itself is now compatible with the Apple supplied build of Python 2.2. At this point, the developer can create a new project in Project Builder, select "Cocoa-Python Application" (a custom template included with PyObjC), and Project Builder will create a new Cocoa application project that is implemented entirely in Python. The project template includes an implementation for a basic application delegate (NSObject subclass) that includes target/actions, outlets, and notification handling. When the 'install' target is used, the resulting application runs completely standalone on any OS X 10.2 machine without requiring that the user has preinstalled PyObjC or a custom build of Python. In comparison to Cocoa-Java, the PyObjC bridge is significantly less intrusive. More on this below. In comparison to Cocoa-AppleScript (AppleScript Studio), the PyObjC bridge presents a development experience that is much closer to pure Cocoa. AppleScript Studio is really a mix of Cocoa widgets into AppleScript style event handling-- the end result is very powerful, but it isn't Cooca programming. At this point, the PyObjC bridge is being used in several production quality projects/products. I.e. it is working now and working extremely well!! (And, again, a huge note of thanks to Ronald -- his work on the subclassing and method dispatch mechanisms made it all possible.) More information interspersed with Jack's and Ronald's text below. On Wednesday, October 16, 2002, at 09:17 AM, Jack Jansen wrote: > [I've added pyobjc-dev to the distribution] > On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote: >>> Something that is open to discussion, I think, is how to map ObjC >>> names to Python names. The current PyObjC code supports two >>> compile-time options, object.message_withFoo_(arg1, arg2) and >>> another that I forget with even more underscores in there (this >>> mapping is ambiguous: it maps to both [object message: withFoo:] and >>> to [object message_withFoo:]). The Java-ObjC brigde has simply >>> defined sensible static mappings for all names used in Cocoa, and >>> the above would probably become something like >>> object.messagewithFoo() or object.messageWithFoo(). Python's current >>> method is more flexible, but boy does it lead to ugly method names >>> in your code... >> >> Changing the mapping from Objective-C names to/from Python names is >> definitely open for discusion. >> >> BTW. The current PyObjC no longer supports object.message__withFoo__. We have been down this path a number of times over the six year history of the PyObjC module. In all cases, we have ended up back with the naming conventions that we have now for a number of reasons. Moving from double underbar to single underbar was definitely a win -- made the code easier to read and write. > I think that what I would like is one static scheme that is the same > (or almost the same) as the Java/ObjC naming scheme, plus a fallback > scheme (which could be the current message_withFoo_ scheme). There may > be a problem here with overloading, though: if I look at AppKitJava > there's often multiple ObjC selectors that map to one Java method > name, I'm not sure how they handle this, especially in the face of > overriding ObjC methods from Java. The key value in the PyObjC module is that it provides an ObjC development experience that is about as close to transparent as can be achieved when mapping from one language to another. One of the most frustrating aspects of doing ObjC/Java (the bridge existed back to WebObjects 3.0 in 1997) was because of the mapping of method names. Specifically, the developer effectively had to learn three APIs deeply to be effective -- the ObjC API, the Java SDK APIs, and this weird permutation of the ObjC APIs as presented in Java. End result; the developer is constantly frustrated by constantly having to do the mapping in their heads. Worse, the mapped representation -- the conversion from, say, setObject:forKey: to setObjectForKey() -- loses the emphasis on the number and order of parameters that is emphasized by ObjC's method naming scheme. From personal experience-- both as a developer and a WebObjects training instructor-- I can confidently say that all of the effort that was put into presenting the ObjC API in Java such that it appeared to be a Java API caused a hell of a lot more confusion than it ever perpetuated clarity! Even if it slightly less Python-Pretty, this... mutableDictionary.setObject_forKey_ ( "foo", "bar" ) ... is ultimately easier to read and maintain than this... mutableDictionary.setObjectForKey( "foo", "bar" ) ... for a number of reasons: - the first is immediately recognizable as an ObjC method call. Regardless of how transparent the bridge is, the bridge is there and it does affect behavior. Trying to hide it makes maintenance significantly more expensive and the introduction of new developers into a project harder. (I helped maintain a mixed ObjC<->Java codebase with 500,000+ lines of code for over 3 years. The bridge was the single largest cause of problems in the project -- that it tried to hide the "crossing of the bridge" just confused things.) - the first form preserves the argumentation information as provided by the traditional ObjC method name (setObject:forKey:)-- the developer can easily map between that syntax and the original ObjC method. The second loses that information and the developer can easily assume that the key should be first. This is a huge problem among my development team with WebObjects 5.x -- all of us make this kind of mistake on a regular basis. - the first has the distinct advantage of allowing the developer to *always* be able to deduce the original ObjC method name by simply looking at the code. The developer doesn't have to go follow some random mapping to try and figure out what the ObjC method's name originally was. > Hmm, even if that isn't possible we could cop out: if the method name > translation routine finds that a certain name isn't in the > dictionaries it would simply add it. Or (more cumbersome, but safer) > there could be a (Python) API MapObjCSelector('message:withFoo', > 'messageWithFoo') which could then also check that this mapping > doesn't conflict with another one. With such a scheme the Python > programmer would have to declare any new ObjC messages it uses, but > the question is how often this will happen. Anything that adds more steps to the bridging process is bad. One of the most powerful and valuable aspects of the PyObjC bridge is that it so totally transparent; much more so than CamlBones (doesn't do subclassing), Java<->ObJC (changes the API) and AppleScript<->ObjC (not intended to be transparent at all). The developer is going to be defining new ObjC methods quite often. The current PyObjC module can complete replace ObjC within a Cocoa project. That is, Python is used to create all of the custom classes that one would normally find in a Cocoa project. As such, the developer is writing lots of custom methods that implement the functionality specific to their application. Certainly, there are many cases where the developer is simply overriding existing Cocoa providing functionality. As it is, many of those methods have to be declared such that the bridge can figure out how to do the dispatch. Very unfortunate, in and of itself, but livable. It would be even more unfortunate if every single action method and other custom methods had to be declared, as well! b.bum |
From: Bill B. <bb...@co...> - 2002-10-16 15:31:56
|
On Wednesday, October 16, 2002, at 02:42 AM, Ronald Oussoren wrote: > On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner > wrote: >> Looking at the implementation, it looks like the problem lies in the >> behavior of the ObjC->Python part of the bridge in that it leaves the >> NSException in a wrapped up state? > That's right. I never got around to implement this, adding this code > should be relatively straightforward. I'll look into it. Thanks. It isn't a huge issue, but anything that makes the bridge more transparent is definitely a boon. BTW: The bridge is working *really* well. I'm using it in a production development setting and have had 0 problems other than of my own making (the exception issue wasn't a big deal). > BTW. I've been playing with libffi and I'm pretty sure it can be used > to remove the need for the register.m file. I already have a function > that returns an 'IMP' for in the Objective-C method dispatch table > (given a method signature). I can't test this at the moment because > libffi refused to build into a shared library... If the inclusion of a shared library requires end users of standalone applications to go through some kind of installation process to have the shlib dumped off in the proper location, I will be very strongly against the inclusion of features that require a shared library. The value of the PyObjC bridge is primarily that it can be used so transparently within the X environment. At this point, the PyObJC is considerably more straightforward to use than the Java-ObjC bridge and is easier to use than the AppleScript Studio bridge. Anything that takes away from that transparency must have a huge return on investment to be worth it. With all that said, eliminating the register.m based dispatch would certainly be a win. Did you receive my earlier message regarding method dispatch within the Java<->ObjC bridge? It was able to do its thing without requiring a mapping for every method and without something like the register.m functionality. I really need to dig more deeply into this particular problem. b.bum |
From: Jack J. <Jac...@cw...> - 2002-10-16 15:25:04
|
On Wednesday, October 16, 2002, at 04:49 , Ronald Oussoren wrote: > To reply to myself... > > Another mapping scheme would be to just drop the colons and translate > the character just beyond colons to uppercase. This would make the > python methodnames more pleasant, although still long and 'foreign > looking': > > [obj setObject:value forKey:key] -> obj.setObjectForKey(value, key) I think the bottom line is: which method makes it easiest to write Python code given Apple's documentation? I must say I haven't looked at the Java Cocoa documentation (actually, I tend to read the ObjC header files mostly) but if that is good then I think we should stick with the Java names. If it isn't good (or nonexistent:-) then an algorithmic name translation scheme is probably best. Something else that might be worthwhile is a helper command that translates ObjC calls to Python. You would then copy [obj setObject: value forKey: key], paste it in your Python script (where it will stay selected) and select the "ObjC methodcall to Python" command to turn it into obj.setObjectForKey(value, key). The only question is how we could get this into Project Builder (into the Python IDE would be easy). -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Ronald O. <ous...@ci...> - 2002-10-16 14:49:22
|
To reply to myself... Another mapping scheme would be to just drop the colons and translate the character just beyond colons to uppercase. This would make the python methodnames more pleasant, although still long and 'foreign looking': [obj setObject:value forKey:key] -> obj.setObjectForKey(value, key) Ronald |
From: Ronald O. <ous...@ci...> - 2002-10-16 14:42:10
|
On Wednesday, Oct 16, 2002, at 15:17 Europe/Amsterdam, Jack Jansen wrote: > > I think that what I would like is one static scheme that is the same > (or almost the same) as the Java/ObjC naming scheme, plus a fallback > scheme (which could be the current message_withFoo_ scheme). There may > be a problem here with overloading, though: if I look at AppKitJava > there's often multiple ObjC selectors that map to one Java method > name, I'm not sure how they handle this, especially in the face of > overriding ObjC methods from Java. I agree that using the naming scheme as from the Java-Cocoa bridge would be usefull. Making up yet another naming scheme would be IMHO be unwise, if only because this would make it very hard to find documentation. W.R.T. mapping multiple selectors onto the same java method in the Java bridge: I suppose these are selectors that are logically 1 method with a number of default arguments, and the ones with less arguments probably call the ones with more arguments: [object foo] -> [object fooWithArg:nil andNum:nil] [object fooWithArg:arg] -> [object fooWithArg:arg andNum:nil] [object fooWithArg:arg andNum:arg2] > > The static scheme could simply be a Python dictionary (or an > NSDictionary, but a Python dictionary is easier to initialize, I > guess) that we initialize with Python code, where the Python code is > generated by running /Developer/Java/Jobs/*.jobs through a script. > Fastest is probably to create both Python->ObjC and ObjC->Python > dictionaries. I was thinking along the same lines. The actual datastructure should be hidden, you'd just call a global function in the objc module to map an Objective-C selector on a Python method name. > > Is it still possible to have two name mapping schemes, where first one > is tried and then the other? Or would this wreak havoc now that we > have two-way inheritance and such? Having two mapping scheme's is not really a problem. That is, unless you want to be able to access a method using both mapping schemes at the same time. The current code does something like the code below while creating a proxy class for and objective-C class: def map_selector(sel): return sel.replace(':', '_') def make_methods(ocClass, clsDict): for meth in ocClass.methods(): clsDict[map_selector(meth.selector)] = wrapMethod(meth) The proxy class is created once including all methods. There is some additional code that recalculates the class dict whenever the method list of the Objective-C class changes. This may happen when loading a bundle that defines additional categories for existing classes. It would be fairly easy to replace the 'map_selector' function by a function that first does a lookup in a translation table. IMHO it is highly unlikely that users define completely new selectors in Python, other than new actions for use in Interface Builder, and I already have written a module that reads the classes.nib from a .NIB 'file' and creates a python module containing the corresponding python classes. Using names without underscores for IBActions is therefore very easy. Ronald |
From: Jack J. <Jac...@cw...> - 2002-10-16 13:17:28
|
[I've added pyobjc-dev to the distribution] On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote: >> Something that is open to discussion, I think, is how to map ObjC >> names to Python names. The current PyObjC code supports two >> compile-time options, object.message_withFoo_(arg1, arg2) and another >> that I forget with even more underscores in there (this mapping is >> ambiguous: it maps to both [object message: withFoo:] and to [object >> message_withFoo:]). The Java-ObjC brigde has simply defined sensible >> static mappings for all names used in Cocoa, and the above would >> probably become something like object.messagewithFoo() or >> object.messageWithFoo(). Python's current method is more flexible, but >> boy does it lead to ugly method names in your code... > > Changing the mapping from Objective-C names to/from Python names is > definitely open for discusion. > > BTW. The current PyObjC no longer supports object.message__withFoo__. I think that what I would like is one static scheme that is the same (or almost the same) as the Java/ObjC naming scheme, plus a fallback scheme (which could be the current message_withFoo_ scheme). There may be a problem here with overloading, though: if I look at AppKitJava there's often multiple ObjC selectors that map to one Java method name, I'm not sure how they handle this, especially in the face of overriding ObjC methods from Java. The static scheme could simply be a Python dictionary (or an NSDictionary, but a Python dictionary is easier to initialize, I guess) that we initialize with Python code, where the Python code is generated by running /Developer/Java/Jobs/*.jobs through a script. Fastest is probably to create both Python->ObjC and ObjC->Python dictionaries. Is it still possible to have two name mapping schemes, where first one is tried and then the other? Or would this wreak havoc now that we have two-way inheritance and such? Hmm, even if that isn't possible we could cop out: if the method name translation routine finds that a certain name isn't in the dictionaries it would simply add it. Or (more cumbersome, but safer) there could be a (Python) API MapObjCSelector('message:withFoo', 'messageWithFoo') which could then also check that this mapping doesn't conflict with another one. With such a scheme the Python programmer would have to declare any new ObjC messages it uses, but the question is how often this will happen. -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Ronald O. <ous...@ci...> - 2002-10-16 06:42:12
|
On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner wrote: > Looking at the implementation, it looks like the problem lies in the > behavior of the ObjC->Python part of the bridge in that it leaves the > NSException in a wrapped up state? That's right. I never got around to implement this, adding this code should be relatively straightforward. I'll look into it. BTW. I've been playing with libffi and I'm pretty sure it can be used to remove the need for the register.m file. I already have a function that returns an 'IMP' for in the Objective-C method dispatch table (given a method signature). I can't test this at the moment because libffi refused to build into a shared library... Ronald |
From: Bill B. <bb...@co...> - 2002-10-16 00:03:30
|
If I implement something like... def foo(self): try: serverAPIVersion = int( versionInfo['currentXmlRpcVersion'] ) serverAppVersion = int( versionInfo['applicationVersion'] ) except KeyError, aKey: NSException.raise_format_(NSInternalInconsistencyException, " ** %s key not found in getVersionInfo() response>" % aKey) ... and am calling this code from ObjC (i.e. objc->python->objc exception), I would expect that the raised NSException would be transparently passed back through to ObjC. That is: NS_DURING [instanceOfPythonObject foo]; NS_HANDLER ... handle the raised NSException here ... NS_ENDHANDLER This would seem to be consistent with the ObjC implementation pattern. That is, it wouldn't matter if -foo is implemented in Python or in the ObjC parent class of the python class, the behavior would be consistent. Looking at the implementation, it looks like the problem lies in the behavior of the ObjC->Python part of the bridge in that it leaves the NSException in a wrapped up state? I'm not sure how this would influence the relatively complex situation of, say, ObjC->Python->ObjC->Python->Objc exception raised... I.e. in the 'ObjC' parts of the stack, you want to raise the exception and let the next level up's interface between Python->ObjC catch it, convert it into the appropriate Python exception, then convert it back into an NSException at the next ObjC->Python extension (keeping in mind that the exception goes from right to left). b.bum |
From: <bb...@ma...> - 2002-10-14 22:24:38
|
Jeez. Can't win. If I put raw dmgs on the site, OmniWeb displays the contents inline... On Monday, October 14, 2002, at 06:12 PM, Frank Steele wrote: > Works like a charm in IE; Chimera shows signs of not recognizing the > .gz > extension. |
From: Frank S. <fs...@mi...> - 2002-10-14 22:13:44
|
Works like a charm in IE; Chimera shows signs of not recognizing the .gz extension. Thanks! Frank > > Try: > > http://pyobjc.sourceforge.net/software/ > > I mirrored everything from friday.com to that site. Of course, I don't > think the project pages are really supposed to be for downloads, but it > isn't like we'll have a *huge* amount of traffic in comparisons to > other projects. It'll do for now -- off to figure out how to do the > whole project file release thing.... > > b.bum > > On Monday, October 14, 2002, at 05:09 PM, Frank Steele wrote: > >> I'm excited about the ObjC-Python bridge, but I have as yet been >> unable to >> download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it >> repeatedly times out. > |
From: <bb...@ma...> - 2002-10-14 21:38:43
|
Try: http://pyobjc.sourceforge.net/software/ I mirrored everything from friday.com to that site. Of course, I don't think the project pages are really supposed to be for downloads, but it isn't like we'll have a *huge* amount of traffic in comparisons to other projects. It'll do for now -- off to figure out how to do the whole project file release thing.... b.bum On Monday, October 14, 2002, at 05:09 PM, Frank Steele wrote: > I'm excited about the ObjC-Python bridge, but I have as yet been > unable to > download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it > repeatedly times out. |
From: <bb...@ma...> - 2002-10-14 21:13:42
|
I'm on it now.... CodeFab's T1 blew up this morning (should be up soon, soon, soon) and friday.com is behind that T1. b.bum On Monday, October 14, 2002, at 05:09 PM, Frank Steele wrote: > I'm excited about the ObjC-Python bridge, but I have as yet been > unable to > download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it > repeatedly times out. > > Is there any way Bill or Ronald could post it to sourceforge? With all > the > good press this has been getting, I'm sure a lot of people are > downloading > it, and more folks will look for it at SF, which of course can support > a > tremendous number of simultaneous downloads.... > > Thanks for all the work -- this is why I signed onto the list months > ago! > > Frank |
From: Frank S. <fs...@mi...> - 2002-10-14 21:10:39
|
I'm excited about the ObjC-Python bridge, but I have as yet been unable to download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it repeatedly times out. Is there any way Bill or Ronald could post it to sourceforge? With all the good press this has been getting, I'm sure a lot of people are downloading it, and more folks will look for it at SF, which of course can support a tremendous number of simultaneous downloads.... Thanks for all the work -- this is why I signed onto the list months ago! Frank |
From: <bb...@ma...> - 2002-10-14 19:39:15
|
Received this this morning -- nice way to start the day! (I asked before posting this and Jonathon gave me permission to forward it along... he also indicated that he would like to see PyObjC ship w/OS X. If enough folks file requests via bugreport.apple.com, it might just happen. :-) b.bum > On Monday, October 14, 2002, at 02:12 AM, Jonathan LaCour wrote: > >> Hello, >> >> I just installed your Python/Obj-C bridge and was able to take an >> existing Python back end and add a beautiful Cocoa UI within an hour >> of use. The ease of development of Python and Cocoa together at >> >> last! >> >> Thank you, thank you, thank you! >> >> Greatfully, >> >> Jonathan LaCour >> 5th Year Senior, Computer Science at Georgia Tech >> Currently Seeking Employment |
From: <bb...@ma...> - 2002-10-14 18:41:26
|
It only supports the old style packages -- not catastraphic, by any means, it'll just require a bit of work to make it generate a proper 10.2 package. The key advantage with 10.2 packages is that it allows the package to explicitly require that it be installed on the root volume only. In general, the package should likely be an mpkg that contains: - a mandatory package containing the compiled module installed into /usr/lib/python2.2/site-packages - an optional package containing the Examples -- default installation into /Developer/Examples/Python/? -an optional package containing the Documentation (if any :-) -- /Developer/Documentation? - an optional package containing the PBX project template(s) -- /Developer/Project Builder Extras/.... b.bum On Sunday, October 13, 2002, at 12:33 PM, Bill Bumgarner wrote: [referencing the buildpkg.py script] > Oh, cool. Does it support the new style packages or only old? I'll > have to check it out... b.bum Wake up. Breathe.... .... keep breathing. |
From: Bill B. <bb...@co...> - 2002-10-13 16:33:37
|
Oh, cool. Does it support the new style packages or only old? I'll have to check it out... b.bum On Sunday, October 13, 2002, at 12:12 PM, Ronald Oussoren wrote: > On Sunday, Oct 13, 2002, at 17:36 Europe/Amsterdam, Bill Bumgarner > wrote: >> The whole package building process is currently manual. It needs to >> be automated and become part of the build process. That isn't 100% >> trivial, but at least Apple has now documented package structure a >> bit better. > It might be easier than you think. There is a script for this in the > Python CVS repository (buildpkg.py by Dinu Gherman) |
From: Ronald O. <ous...@ci...> - 2002-10-13 16:12:27
|
On Sunday, Oct 13, 2002, at 17:36 Europe/Amsterdam, Bill Bumgarner wrote: > The whole package building process is currently manual. It needs to > be automated and become part of the build process. That isn't 100% > trivial, but at least Apple has now documented package structure a bit > better. It might be easier than you think. There is a script for this in the Python CVS repository (buildpkg.py by Dinu Gherman) Ronald |
From: Bill B. <bb...@co...> - 2002-10-13 15:36:20
|
I put a new version of the binary package on http://www.friday.com/software/python/ It contains the Readme and License text. The Readme had to be edited to only use newlines at the end of the lines. New package definition is in repository; but it won't work for anyone but me, i bet, because of path references. The command line 'package' tool provided by apple is totally and completely broken -- don't bother with it. The whole package building process is currently manual. It needs to be automated and become part of the build process. That isn't 100% trivial, but at least Apple has now documented package structure a bit better. b.bum |
From: Bill B. <bb...@co...> - 2002-10-13 14:43:00
|
On Sunday, October 13, 2002, at 04:01 AM, Ronald Oussoren wrote: > This is pretty neat. I did find something to nag about: I'd prefer if > the installer showed in the README file. That'd make sense -- I would also like to shove a/the license in (currently, the MIT license is in the repository -- it seems to be the easiest / most open license around and I couldn't find a concise and appropriate version of the python license in a module context). Oh. Duh. There is a Package Format Notes menu that I *completely* ignored... will fix. > > Are there any reasons left to postpone a new release? If not we could > publish this and a source archive on sourceforge. None that I can think of. This version seems to be pretty rock solid to the point of being able to support complex application development. The examples could use some cleanup, but that will always be the case. > > BTW. The current CVS version will probably _not_ compile on 10.1, due > to the additional enum-labels in the AppKit package. Oh -- I forgot about that. I'll have to update the notes on my blog. b.bum |
From: tmk <li...@ne...> - 2002-10-13 11:30:42
|
Yo, Just a small note to say a huge THANK YOU to all of you guys and especially to bbum, Ronald, Jack for making it not only possible but even easy to develop Cocoa apps in Python. I've been longing for being able to do this for so many years. This is one of the coolest thing to happen since Mac OS X. = tmk = |
From: Ronald O. <ous...@ci...> - 2002-10-13 08:01:54
|
This is pretty neat. I did find something to nag about: I'd prefer if the installer showed in the README file. Are there any reasons left to postpone a new release? If not we could publish this and a source archive on sourceforge. BTW. The current CVS version will probably _not_ compile on 10.1, due to the additional enum-labels in the AppKit package. Ronald On Saturday, Oct 12, 2002, at 23:01 Europe/Amsterdam, Bill Bumgarner wrote: > I put together an installer package that includes the PyObjC module > and the Project Builder template. See... > > http://radio.weblogs.com/0100490/ > > For more information. > > I also reorganized the README a bit to reflect the current state of > things. > > b.bum > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > |
From: Bill B. <bb...@co...> - 2002-10-12 21:01:32
|
I put together an installer package that includes the PyObjC module and the Project Builder template. See... http://radio.weblogs.com/0100490/ For more information. I also reorganized the README a bit to reflect the current state of things. b.bum |
From: Bill B. <bb...@co...> - 2002-10-12 19:25:10
|
I took Jiva's suggestion and created a Project Templates directory within the pyobjc source tree. It currently contains a single template; Cocoa-Python Application. It is an edited copy of the standard Cocoa Application template. When used, the template creates a Cocoa project with the following features/attributes: - includes a Main.py that initializes the bridge appropriately - includes a copy files phase that copies the pyobjc module into the app wrapper on installation - includes a basic application delegate class implemented in Python (MyAppDelegate.py) - upon execution, the application presents a simple window with a button and a field. Click the button and an action handler fills the field with data. - only links the Foundation framework, but includes AppKit and Cocoa for indexing purposes Damned handy -- thanks Jiva! Some notes on creating templates: - always remove the .pbxuser file from the pbproj directory - make sure and edit the list of files that need expansion in the TemplateInfo.plist file (found in the pbproj) - it is also possible to automatically rename files b.bum |
From: Bill B. <bb...@co...> - 2002-10-12 14:43:28
|
Excellent. I'm reworking it a bit to provide a more complete example of how to set up a project "out of the box". A basic "Hello World", if you will. More like the multi-document Cocoa example (which that template will be the next to port over). I'll commit something into CVS shortly.... I see that PyObjC made DayPop -- seems we have caused quite the stir in the technical 'blogging community. http://www.daypop.com/top/ b.bum On Saturday, October 12, 2002, at 01:24 AM, Jiva DeVoe wrote: > I have taken your sample project and put it into a template suitable > for putting into the rest of the project builder templates in > /Developer/ProjectBuilder Extras > > You can download this template at: > > http://www.devoesquared.com/pyobjc_template.tar.gz > > Feel free to add this to cvs if you guys find it useful. |
From: Ronald O. <ous...@ci...> - 2002-10-12 05:52:18
|
On Saturday, Oct 12, 2002, at 00:56 Europe/Amsterdam, Jiva DeVoe wrote: > So we can now rapidly prototype in python, and when we find > bottlenecks needing to be faster, we recode that code in Obj-C. This > almost seems too good to be true! :) That was my plan, so this better be true ;-) I'd like to avoid the 'recode in Obj-C' part though. Ronald |