pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] another odd problem

[Steven D. A. <st...@ne...>]

Thanks to Ronald and Martina for their comments regarding the non-retained
objects that acted as datasources for an NSComboBox.  Setting those objects
as instance variables in the controller object did indeed solve that
problem.  However, I have encountered another weird problem which seems like
a possible bug.

Essentially, it seems classes that inherit from Foundation.NSObject do not
correctly see methods in superclasses before the one that inherited from
NSObject.  However, note that dir does show the attribute!  Consider the
following code snippet:

    import Foundation
    class ListManager:
        def init( self ):
            return self
        def key_for_index( self, index ):
            print "INDEX = ", index
    
    class foo( Foundation.NSObject, ListManager ):
        def init( self ):
            ListManager.init( self )
            return self
    
    i = foo.alloc().init()
    if 'key_for_index' in dir( i ):
        present = "is"
    else:
        present = "is not"
    
    print "dir shows that key_for_index %s an attribute of i" % present
    i.key_for_index( 5 )

If you run this code, you get the following:

    >>> print "dir shows that key_for_index %s an attribute of i" % present
    dir shows that key_for_index is an attribute of i
    >>> i.key_for_index( 5 )
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    AttributeError: 'foo' object has no attribute 'key_for_index'


However, if you modify the code to avoid inheriting from
Foundation.NSObject, you get the expected behavior:

    import Foundation
    class ListManager:
        def init( self ):
            return self
        def key_for_index( self, index ):
            print "INDEX = ", index
    
    class foo( ListManager ):
        def init( self ):
            ListManager.init( self )
            return self
    
    i = foo()
    if 'key_for_index' in dir( i ):
        present = "is"
    else:
        present = "is not"
    
    print "dir shows that key_for_index %s an attribute of i" % present
    i.key_for_index( 5 )

The result:

    >>> print "dir shows that key_for_index %s an attribute of i" % present
    dir shows that key_for_index is an attribute of i
    >>> i.key_for_index( 5 )
    INDEX =  5


[...] After playing around with this awhile, I moved Foundation.NSObject to
the ListManager class and now it seems to work.  But is it a bug that the
code in the first example above fails to work?

-- 
Steven D. Arnold                             st...@ne...
     "One has a moral responsibility to disobey unjust laws."
                        Martin Luther King
News and Opinion Covering Free-Speech Issues in Media & Technology:
            http://prime.neosynapse.net:8080/index.php

Re: [Pyobjc-dev] signal 11 when trying to access an NSComboBox's data source

[Ronald O. <ous...@ci...>]

On Friday, 8 August, 2003, at 23:35, Steven D. Arnold wrote:

> Hi,
>
> I am writing a program which has a controller object with an  
> awakeFromNib
> function that begins like this:
>
>     def awakeFromNib( self ):
>         self.word_type.setDataSource_( WordTypeManager.alloc().init(  
> self.db
> ) )
>         print "will this fail?"
>         print "value = %s" % self.word_type.dataSource()
>         print "no, it worked"
>
> The program dies on a signal 11 on the line where it attempts to print  
> the
> data source.  We never see the "value =" text or the "no, it worked"  
> string.

Does it work any better when you assign the WorkTypeManager instance to  
an instance variable? As Martina already noted, the combobox probably  
doesn't retain it's datasource. There's not much we can do about that.  
Cocoa seems to do this quite often, probably to avoid reference  
counting cycles. Let's hope that Apple adds a real garbage collector in  
the future.

The documentations mentions this, but obviously not clearly enough.  
I'll try to improve the documentation.

BTW. Wouldn't it be possible to set the datasource within Interface  
builder, and use 'self.word_type.dataSource().setDB(self.db)' to finish  
initialising the datasource? That way you don't have to worry about  
reference counts at all.

>
> WordTypeManager is a class that is declared like this:
>
> class WordTypeManager( Foundation.NSObject,  
> AppKit.NSComboBoxDataSource,
> ListManager ):

BTW. You don't have to subclass from informal protocols anymore in  
1.0b1.

>
>     def init( self, db ):
>
>     def numberOfItemsInComboBox_( self, comboBox ):
>
>     def comboBox_objectValueForItemAtIndex_( self, comboBox, index ):
>
>     def comboBox_indexOfItemWithStringValue_( self, comboBox,  
> str_value ):
>
> I can provide more detail about the code if needed.
>
> I have verified that self.word_type is an NSComboBox and that the  
> class's
> outlet is connected to the right object in Interface Builder.
>
> I am using Python 2.3 (final) and PyObjC 1.0b1 (not CVS).  Note that I
> recently upgraded both Python and PyObjC, and the program worked fine  
> before
> this upgrade, although I last used the program a couple months ago.  I  
> am on
> Mac OS X 10.2.6, on a dual-processor 1 GHz machine.
>
> Any ideas what might be causing this problem?
>
> --  
> Steven D. Arnold                             st...@ne...
>      "One has a moral responsibility to disobey unjust laws."
>                         Martin Luther King
> News and Opinion Covering Free-Speech Issues in Media & Technology:
>             http://prime.neosynapse.net:8080/index.php
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct; 
> at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] signal 11 when trying to access an NSComboBox's data source

[Martina O. <Ma...@Oe...>]

Hi Steven,

>     def awakeFromNib( self ):
>         self.word_type.setDataSource_( WordTypeManager.alloc().init( 
> self.db
> ) )

This sounds like the usual objc reference counting woes. Probably 
setDataSource: doesn't retain the passed object, so you WordTypeManager 
will be released right away.

Just keep a reference to you WordTypeManager around somewhere, e.g.:

         self.word_type_manager = WordTypeManager.alloc().init( self.db )
         self.word_type.setDataSource_( self.word_type_manager )

ciao
Martina

Re: [Pyobjc-dev] Some PyObC tweaks for using EOF and custom frameworks

[Ronald O. <ous...@ci...>]

On Saturday, 9 August, 2003, at 07:56, Pierce T. Wetter III wrote:

>
>  Background:
>
>   I'm using EOF 4.5, and I wanted to be able to use python to write  
> test scripts, mini programs, and scripts that interacted with both our  
> object model, and shell tools.
>
>  Every thing works ok, except I had to make some tweaks.

It's great to hear that PyObjC is still useable with EOF, even after  
the extensive changes I made to the bridge over the last year.

>
>  1. I have to touch NSCalendarDate after loading Foundation and before  
> loading any other frameworks via loadBundle. I think this causes  
> +initialize for the various Foundation classes early on, which  
> probably should have been done by the "import Foundation" step  
> originally, but that might be tough. I'm using NSCalendarDate because  
> NSCalendarDate had a +initialize method that was deadlocking, but  
> using it seemed to fix everything.
>
>  Doing this after the loadBundle call caused problems with both  
> Foundation and the loaded frameworks.
>
> i.e I have to do some VOODOO:
>
> import objc
> import Foundation
>
> #VOODOO
> from Foundation import NSCalendarDate
> NSCalendarDate.date().description()
>
> objc.loadBundle("EOAccess",globals(),bundle_path="/System/Library/ 
> Frameworks/EOAccess.framework")

This is odd. I'll try to reproduce this with another framework, I don't  
think we have old WebObjects CD's lying around at the office. I noticed  
you can download a trial version of WebObjects 5.x, but that seems to  
be java based.

>
>
>  2. EOF does some hackery on the ObjC where objects that haven't yet  
> been fetched from the database have a fake "isa" pointer. When the  
> object gets fetched, the isa pointer get reset to that of the real  
> class.
>
>   This crashes on the Python side, but it works if you pre resolve the  
> fault on the ObjC side.

That doesn't surprise me. Do you know if there is a way to detect this  
fake isa pointer? Calling  [object self] everytime we want to access an  
Objective-C object would be way to expensive, especially if this is  
only needed for WebObjects.

I've checked the code and think this may be caused by the call to  
__pyobjc_PythonObject__ (a few lines below the fragment you included  
below). From about line 50 in objc_support.m we define a category on  
NSObject that defines this method. The fake 'isa' obviously doesn't  
point to a subclass of NSObject. Could you try to change 'NSObject' to  
'Object' in the declaration and definition of that category and check  
if that solves your problem?

That probably doesn't help with objects that get invalidated. PyObjC  
doesn't deal gracefully with objects that change their class.

>
> That is in Python:
>
> mystock= trade.stock()
>
> bus errors, but
>
>  mystock= trade.valueForKeyPath_("stock.self")
>
> works.
>
>  Given this, the fix is easy.
>
>  In objc_support.m:pythonify_c_value we have:
>
> 	case _C_ID:
> 	{
> 		id obj = *(id *) datum;
> 		if (obj == nil) {
>
> Which becomes:
>
> 	case _C_ID:
> 	{
> 		id obj = *(id *) datum;
> 		obj=[obj self];
>
> 		if (obj == nil) {
>
>  This forces the fault to resolve on the Objective-C side before  
> python creates the python object. Then:
>
> mystock= trade.stock()
>
>  Will work. I'm not sure what would happen if an object got  
> invalidated. It seems in that case, you'd want to call [obj self]  
> before doing any method calls on it, but I wasn't sure where to put  
> that.
>
>  Pierce
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct; 
> at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Some PyObC tweaks for using EOF and custom frameworks

[Pierce T. W. I. <pi...@ma...>]

  Background:

   I'm using EOF 4.5, and I wanted to be able to use python to write  
test scripts, mini programs, and scripts that interacted with both our  
object model, and shell tools.

  Every thing works ok, except I had to make some tweaks.

  1. I have to touch NSCalendarDate after loading Foundation and before  
loading any other frameworks via loadBundle. I think this causes  
+initialize for the various Foundation classes early on, which probably  
should have been done by the "import Foundation" step originally, but  
that might be tough. I'm using NSCalendarDate because NSCalendarDate  
had a +initialize method that was deadlocking, but using it seemed to  
fix everything.

  Doing this after the loadBundle call caused problems with both  
Foundation and the loaded frameworks.

i.e I have to do some VOODOO:

import objc
import Foundation

#VOODOO
from Foundation import NSCalendarDate
NSCalendarDate.date().description()

objc.loadBundle("EOAccess",globals(),bundle_path="/System/Library/ 
Frameworks/EOAccess.framework")


  2. EOF does some hackery on the ObjC where objects that haven't yet  
been fetched from the database have a fake "isa" pointer. When the  
object gets fetched, the isa pointer get reset to that of the real  
class.

   This crashes on the Python side, but it works if you pre resolve the  
fault on the ObjC side.

That is in Python:

mystock= trade.stock()

bus errors, but

  mystock= trade.valueForKeyPath_("stock.self")

works.

  Given this, the fix is easy.

  In objc_support.m:pythonify_c_value we have:

	case _C_ID:
	{
		id obj = *(id *) datum;
		if (obj == nil) {

Which becomes:

	case _C_ID:
	{
		id obj = *(id *) datum;
		obj=[obj self];

		if (obj == nil) {

  This forces the fault to resolve on the Objective-C side before python  
creates the python object. Then:

mystock= trade.stock()

  Will work. I'm not sure what would happen if an object got  
invalidated. It seems in that case, you'd want to call [obj self]  
before doing any method calls on it, but I wasn't sure where to put  
that.

  Pierce

[Pyobjc-dev] signal 11 when trying to access an NSComboBox's data source

[Steven D. A. <st...@ne...>]

Hi,

I am writing a program which has a controller object with an awakeFromNib
function that begins like this:

    def awakeFromNib( self ):
        self.word_type.setDataSource_( WordTypeManager.alloc().init( self.db
) )
        print "will this fail?"
        print "value = %s" % self.word_type.dataSource()
        print "no, it worked"

The program dies on a signal 11 on the line where it attempts to print the
data source.  We never see the "value =" text or the "no, it worked" string.

WordTypeManager is a class that is declared like this:

class WordTypeManager( Foundation.NSObject, AppKit.NSComboBoxDataSource,
ListManager ):

    def init( self, db ):

    def numberOfItemsInComboBox_( self, comboBox ):
        
    def comboBox_objectValueForItemAtIndex_( self, comboBox, index ):
        
    def comboBox_indexOfItemWithStringValue_( self, comboBox, str_value ):

I can provide more detail about the code if needed.

I have verified that self.word_type is an NSComboBox and that the class's
outlet is connected to the right object in Interface Builder.

I am using Python 2.3 (final) and PyObjC 1.0b1 (not CVS).  Note that I
recently upgraded both Python and PyObjC, and the program worked fine before
this upgrade, although I last used the program a couple months ago.  I am on
Mac OS X 10.2.6, on a dual-processor 1 GHz machine.

Any ideas what might be causing this problem?

-- 
Steven D. Arnold                             st...@ne...
     "One has a moral responsibility to disobey unjust laws."
                        Martin Luther King
News and Opinion Covering Free-Speech Issues in Media & Technology:
            http://prime.neosynapse.net:8080/index.php

Re: [Pyobjc-dev] Errors building standalone with 1.0b1 & Apple Python2.2

[Bob I. <bo...@re...>]

On Friday, Aug 8, 2003, at 15:51 America/New_York, Kevin Marks wrote:

> When I pass --standalone or --semistandalone to my build instead of 
> --link using 1.0b1 and Apple Python 2.2 on Jag I get this:
>
>> Finding module dependencies
>> Traceback (most recent call last):
>>   File "buildapp.py", line 6, in ?
>>     nibname = "MainMenu",
>>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
>> line 892, in buildapp
>>     main(builder)
>>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
>> line 879, in main
>>     builder.setup()
>>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
>> line 423, in setup
>>     self.findDependencies()
>>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
>> line 591, in findDependencies
>>     import modulefinder
>> ImportError: No module named modulefinder
>
> Do I need to change some install settings, or install Python 2.3 ?

I don't know about your PyObjC installation problem specifically, but 
modulefinder is a new module that comes with 2.3.  You should install 
2.3 anyways.. it's faster, more capable, less buggy, etc.  Especially 
on the mac.  It's also what will be in Panther.

-bob

[Pyobjc-dev] Errors building standalone with 1.0b1 & Apple Python2.2

[Kevin M. <kev...@ma...>]

When I pass --standalone or --semistandalone to my build instead of 
--link using 1.0b1 and Apple Python 2.2 on Jag I get this:

> Finding module dependencies
> Traceback (most recent call last):
>   File "buildapp.py", line 6, in ?
>     nibname = "MainMenu",
>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
> line 892, in buildapp
>     main(builder)
>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
> line 879, in main
>     builder.setup()
>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
> line 423, in setup
>     self.findDependencies()
>   File "/usr/lib/python2.2/site-packages/PyObjC/bundlebuilder.py", 
> line 591, in findDependencies
>     import modulefinder
> ImportError: No module named modulefinder

Do I need to change some install settings, or install Python 2.3 ?

Re: [Pyobjc-dev] Upgrade to PyObjC 1.0beta

[Chris R. <cp...@em...>]

On Friday, August 8, 2003, at 11:21  AM, Ronald Oussoren wrote:

> On Friday, 8 August, 2003, at 17:10, Bob Swerdlow wrote:
>
>> I finally got around to upgrading my application to use PyObjC 1.0 
>> beta 1
>> from PyObjC 0.9.
>>
>> The upgrade was easy, but I ran into one problem:
>>
>>     appleScript = NSAppleScript.alloc().initWithSource_(strScript)
>>     result = appleScript.executeAndReturnError_(None)
>>
>> produced this error for the second line:
>>
>>     TypeError: Need 0 arguments, got 1
>>
>> This had not happened in PyObjC 0.9.  When I changed it to:
>>
>>     result = appleScript.executeAndReturnError_()
>>
>> the code worked and the error went away.
>>
>> I'm not sure I understand why this is so, as that function is 
>> documented as:
>>    - (NSAppleEventDescriptor *)executeAndReturnError:(NSDictionary
>> **)errorInfo
>
> That's a bug in version 0.9. The 'executeAndReturnError:' method has 
> an output argument, you don't have to supply those when calling 
> methods.

But won't result then be a tuple of the (AE descriptor, error info), 
not just the AE descriptor? (That's probably not what Bob's expecting, 
so I just wanted to clarify for him.)

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

Re: [Pyobjc-dev] Upgrade to PyObjC 1.0beta

[Ronald O. <ous...@ci...>]

On Friday, 8 August, 2003, at 17:10, Bob Swerdlow wrote:

> I finally got around to upgrading my application to use PyObjC 1.0 
> beta 1
> from PyObjC 0.9.
>
> The upgrade was easy, but I ran into one problem:
>
>     appleScript = NSAppleScript.alloc().initWithSource_(strScript)
>     result = appleScript.executeAndReturnError_(None)
>
> produced this error for the second line:
>
>     TypeError: Need 0 arguments, got 1
>
> This had not happened in PyObjC 0.9.  When I changed it to:
>
>     result = appleScript.executeAndReturnError_()
>
> the code worked and the error went away.
>
> I'm not sure I understand why this is so, as that function is 
> documented as:
>    - (NSAppleEventDescriptor *)executeAndReturnError:(NSDictionary
> **)errorInfo

That's a bug in version 0.9. The 'executeAndReturnError:' method has an 
output argument, you don't have to supply those when calling methods.

[Pyobjc-dev] Upgrade to PyObjC 1.0beta

[Bob S. <rsw...@tr...>]

I finally got around to upgrading my application to use PyObjC 1.0 beta 1
from PyObjC 0.9.

The upgrade was easy, but I ran into one problem:

    appleScript = NSAppleScript.alloc().initWithSource_(strScript)
    result = appleScript.executeAndReturnError_(None)

produced this error for the second line:

    TypeError: Need 0 arguments, got 1

This had not happened in PyObjC 0.9.  When I changed it to:

    result = appleScript.executeAndReturnError_()

the code worked and the error went away.

I'm not sure I understand why this is so, as that function is documented as:
   - (NSAppleEventDescriptor *)executeAndReturnError:(NSDictionary
**)errorInfo
at
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSAppleScript.html

Thanks for creating a great tool.

Bob Swerdlow
COO
Transpose
rsw...@tr...
207-781-8284
http://www.transpose.com

----------------------------------
Fight Spam!
Add this link to your signature (as I did): http://wecanstopspam.org
Click through to find out more.
----------------------------------

Re: [Pyobjc-dev] Re: Subclassing NSCell?

[Joshua K. <jo...@ro...>]

I updated to MacPython 2.3 and installed with the Package Manager and  
the crash project worked.  Thanks!


On Thursday, August 7, 2003, at 12:19 PM, Ronald Oussoren wrote:

>
> On Thursday, 7 August, 2003, at 07:52, Ronald Oussoren wrote:
>
>>
>> On Wednesday, 6 August, 2003, at 21:56, Joshua Kifer wrote:
>>
>>> Has this been resolved yet?  I'm using the current version of pyobc  
>>> from cvs and am having exactly the issue that Mitch describe in his  
>>> initial post for this thread.
>>
>> I certainly had the impression that this issue was solved. There is a  
>> bug in libffi, the libffi tree on our website and the one included in  
>> the 1.0b1 have been patched. I've told the libffi people about this  
>> bugs, but hope they won't include my patch as it is very ugly and  
>> probably not entirely correct.
>
> After rereading my responce I noticed this may be interpreted as "go  
> away, there is no problem".
>
> Are you using the latest libffi tarball on our website? If so, does  
> the program attached to  
> http://sourceforge.net/tracker/ 
> index.php?func=detail&aid=738252&group_id=14534&atid=114534 crash as  
> well?
>
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/ 
> direct;at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Re: Subclassing NSCell?

[Joshua K. <jo...@ro...>]

Thanks for the response -- I somehow missed your first reply.  I'll  
verify that I'm all up to date and tinker with it some more.  Will let  
you know if I continue having a problem.


On Thursday, August 7, 2003, at 12:19 PM, Ronald Oussoren wrote:

>
> On Thursday, 7 August, 2003, at 07:52, Ronald Oussoren wrote:
>
>>
>> On Wednesday, 6 August, 2003, at 21:56, Joshua Kifer wrote:
>>
>>> Has this been resolved yet?  I'm using the current version of pyobc  
>>> from cvs and am having exactly the issue that Mitch describe in his  
>>> initial post for this thread.
>>
>> I certainly had the impression that this issue was solved. There is a  
>> bug in libffi, the libffi tree on our website and the one included in  
>> the 1.0b1 have been patched. I've told the libffi people about this  
>> bugs, but hope they won't include my patch as it is very ugly and  
>> probably not entirely correct.
>
> After rereading my responce I noticed this may be interpreted as "go  
> away, there is no problem".
>
> Are you using the latest libffi tarball on our website? If so, does  
> the program attached to  
> http://sourceforge.net/tracker/ 
> index.php?func=detail&aid=738252&group_id=14534&atid=114534 crash as  
> well?
>
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/ 
> direct;at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Re: Subclassing NSCell?

[Ronald O. <ous...@ci...>]

On Thursday, 7 August, 2003, at 07:52, Ronald Oussoren wrote:

>
> On Wednesday, 6 August, 2003, at 21:56, Joshua Kifer wrote:
>
>> Has this been resolved yet?  I'm using the current version of pyobc  
>> from cvs and am having exactly the issue that Mitch describe in his  
>> initial post for this thread.
>
> I certainly had the impression that this issue was solved. There is a  
> bug in libffi, the libffi tree on our website and the one included in  
> the 1.0b1 have been patched. I've told the libffi people about this  
> bugs, but hope they won't include my patch as it is very ugly and  
> probably not entirely correct.

After rereading my responce I noticed this may be interpreted as "go  
away, there is no problem".

Are you using the latest libffi tarball on our website? If so, does the  
program attached to  
http://sourceforge.net/tracker/index.php? 
func=detail&aid=738252&group_id=14534&atid=114534 crash as well?


Ronald

Re: [Pyobjc-dev] Doing release 1.0 soon?

[Bob I. <bo...@re...>]

On Thursday, Aug 7, 2003, at 12:03 America/New_York, b.bum wrote:

> On Thursday, August 7, 2003, at 2:48, Dinu Gherman wrote:
>> What's the plan, then? Supporting two different sets of templates,
>> one for 10.3 and one for < 10.3? If that works ok, fine.
>
> It isn't a problem.

It's also the only way to do it, AFAIK :)

-bob

Re: [Pyobjc-dev] Doing release 1.0 soon?

[b.bum <bb...@ma...>]

On Thursday, August 7, 2003, at 2:48, Dinu Gherman wrote:
> What's the plan, then? Supporting two different sets of templates,
> one for 10.3 and one for < 10.3? If that works ok, fine.

It isn't a problem.

b.bum

Re: [Pyobjc-dev] Doing release 1.0 soon?

[Dinu G. <gh...@da...>]

b.bum:

> The project templates are not yet up to date -- the Project Builder 
> ting
> templates will work in Xcode, but are totally sub-optimal for Python
> 2.3 (see the PR :).

What's the plan, then? Supporting two different sets of templates,
one for 10.3 and one for < 10.3? If that works ok, fine.

Dinu

--
Dinu C. Gherman
......................................................................
"If you tell the truth, you don't have to remember anything."
(Mark Twain)

Re: [Pyobjc-dev] Doing release 1.0 soon?

[Ronald O. <ous...@ci...>]

On Wednesday, 6 August, 2003, at 23:20, Dan Grassi wrote:

> On Wednesday, August 6, 2003, at 01:48  PM, Ronald Oussoren wrote:
>
>> Please test the current CVS
>
> Is this supposed to work on Panther?  Compile with xcode?  If so I 
> will test it.

The core bridge is supposed to work on Panther, the PB/Xcode templates 
still need some work. However, Panther support is not important enough 
to hold up this release and I won't delay the release if there are 
Panther-only issues.

I do want to know about Panther-related issues, Panther support will be 
important when OS X 10.3 is actually released. With some luck I'll have 
a binary installer within a week of its release.

Ronald

Re: [Pyobjc-dev] Re: Subclassing NSCell?

[Ronald O. <ous...@ci...>]

On Wednesday, 6 August, 2003, at 21:56, Joshua Kifer wrote:

> Has this been resolved yet?  I'm using the current version of pyobc 
> from cvs and am having exactly the issue that Mitch describe in his 
> initial post for this thread.

I certainly had the impression that this issue was solved. There is a 
bug in libffi, the libffi tree on our website and the one included in 
the 1.0b1 have been patched. I've told the libffi people about this 
bugs, but hope they won't include my patch as it is very ugly and 
probably not entirely correct.

Ronald

Re: [Pyobjc-dev] Doing release 1.0 soon?

[b.bum <bb...@ma...>]

The project templates are not yet up to date -- the Project Builder 
templates will work in Xcode, but are totally sub-optimal for Python 
2.3 (see the PR :).

b.bum

Re: [Pyobjc-dev] Doing release 1.0 soon?

[Bob I. <bo...@re...>]

On Wednesday, Aug 6, 2003, at 17:20 America/New_York, Dan Grassi wrote:

> On Wednesday, August 6, 2003, at 01:48  PM, Ronald Oussoren wrote:
>
>> Please test the current CVS
>
> Is this supposed to work on Panther?  Compile with xcode?  If so I 
> will test it.

It worked last time I tried it.. but my panther machine died so I can't 
test anymore.

-bob

Re: [Pyobjc-dev] Doing release 1.0 soon?

[Dan G. <dg...@Le...>]

On Wednesday, August 6, 2003, at 01:48  PM, Ronald Oussoren wrote:

> Please test the current CVS

Is this supposed to work on Panther?  Compile with xcode?  If so I will 
test it.

Dan

[Pyobjc-dev] Re: Subclassing NSCell?

[Joshua K. <jo...@ro...>]

Has this been resolved yet?  I'm using the current version of pyobc 
from cvs and am having exactly the issue that Mitch describe in his 
initial post for this thread.

[Pyobjc-dev] Doing release 1.0 soon?

[Ronald O. <ous...@ci...>]

Hi,

I think it is about time to do a 1.0 release. All bugs I know of have 
been fixed, and the end-user documentation is good enough. That doesn't 
mean the documentation doesn't need work, but that can wait for a 
future release.

Please test the current CVS version and mention any bugs you find 
(including documentation bugs). I'd like to do the 1.0 release next 
Wednesday.

Ronald

[Pyobjc-dev] In need of trust in partnership

[<os...@ti...>]

RlJPTSBUSEUgT0ZGSUNFIE9GIEVOR1IuVElNTVkgQUxJLg0KRkVERVJBTCBNSU5JU1RSWSBPRiBX
T1JLUyBBTkQgSE9VU0lORw0KRkVERVJBTCBTRUNSRVRBUklBVCBPRkZJQ0UgQ09NUExFWA0KRkFM
T01PLCBJS09ZSSAtIExBR09TLg0KICAgICAgICAgICAgICAgDQpEZWFyIFNpci9NYWRhbQ0KDQpG
aXJzdCwgSSBtdXN0IHNvbGljaXQgIHlvdXIgc3RyaWN0ZXN0IGNvbmZpZGVuY2UgaW4NCnRoaXMg
dHJhbnNhY3Rpb24sIHRoaXMgaXMgYnkgIHZpcnR1ZSBvZiBpdCdzIG5hdHVyZSBhcw0KYmVpbmcg
dXR0ZXJseSBjb25maWRlbnRpYWwgYW5kIHRvcCBzZWNyZXQgYXMgeW91IHdlcmUNCmludHJvZHVj
ZWQgdG8gdXMgaW4gY29uZmlkZW5jZSB0aHJvdWdoIHRoZSBOaWdlcmlhbg0KQ2hhbWJlciBvZiBD
b21tZXJjZSwgZm9yZWlnbiB0cmFkZSBkaXZpc2lvbi4NCg0KV2UgYXJlIHRvcCBvZmZpY2lhbHMg
ZnJvbSB0aGUgRmVkZXJhbCBNaW5pc3RyeSBvZg0KV29ya3MgYW5kIEhvdXNpbmcsKEZNV0gpLEZl
ZGVyYWwgTWluaXN0cnkgb2YgRmluYW5jZQ0KYW5kIHRoZSBQcmVzaWRlbmN5LCBtYWtpbmcgdXAg
dGhlIENvbnRyYWN0IFJldmlldw0KUGFuZWwgKENSUCkgc2V0IHVwIGJ5IHRoZSBGZWRlcmFsIEdv
dmVybm1lbnQgb2YNCk5pZ2VyaWEgdG8gcmV2aWV3IGNvbnRyYWN0cyBhd2FyZGVkIGJ5IHRoZSBw
YXN0DQptaWxpdGFyeSBhZG1pbmlzdHJhdGlvbi4NCg0KSW4gdGhlIGNvdXJzZSBvZiBvdXIgd29y
ayBvbiB0aGUgQ1JQLCB3ZSBkaXNjb3ZlcmVkDQp0aGlzIGZ1bmQgd2hpY2ggcmVzdWx0ZWQgZnJv
bSBncm9zc2x5IG92ZXItaW52b2ljZWQNCmNvbnRyYWN0cyAgd2hpY2ggd2VyZSBleGVjdXRlZCBm
b3IgdGhlRk1XJkggZHVyaW5nIHRoZQ0KbGFzdCBhZG1pbmlzdHJhdGlvbi4gVGhlIGNvbXBhbmll
cyB0aGF0IGV4ZWN1dGVkIHRoZQ0KY29udHJhY3RzIGhhdmUgYmVlbiBkdWx5IHBhaWQgYW5kIHRo
ZSBjb250cmFjdHMNCmNvbW1pc3Npb25lZCBsZWF2aW5nIHRoZSBzdW0gb2YgVVMkMTcuNCBNaWxs
aW9uDQpmbG9hdGluZyBpbiB0aGUgZXNjcm93IGFjY291bnQgb2YgdGhlIENlbnRyYWwgQmFuayBv
Zg0KTmlnZXJpYSByZWFkeSBmb3IgcGF5bWVudC4NCg0KSSBoYXZlIHRoZXJlZm9yZSBiZWVuIG1h
bmRhdGVkIGFzIGEgbWF0dGVyIG9mIHRydXN0IGJ5DQpteSBjb2xsZWFndWVzIGluIHRoZSBwYW5l
bCB0byBsb29rIGZvciBhbiBvdmVyc2Vhcw0KcGFydG5lciB0byB3aG9tIHdlIGNvdWxkIHRyYW5z
ZmVyIHRoZSBzdW0gb2YgVVMkMTcuNE0NCmxlZ2FsbHkgc3ViY29udHJhY3RpbmcgdGhlIGVudGl0
bGVtZW50IHRvIHlvdXINCmNvbXBhbnkuIFRoaXMgaXMgYmVhcmluZyBpbiBtaW5kIHRoYXQgb3Vy
IGNpdmlsDQpzZXJ2aWNlIGNvZGUgb2YgY29uZHVjdCBmb3JiaWRzIHVzIGZyb20gb3duaW5nIA0K
Zm9yZWlnbiBjb21wYW55IG9yIHJ1bm5pbmcgIGZvcmVpZ24gYWNjb3VudCB3aGlsZSBpbg0KZ292
ZXJubWVudCBzZXJ2aWNlIGhlbmNlIHRoZSBuZWVkIGZvciBhbiBvdmVyc2Vhcw0KcGFydG5lci4N
Cg0KV2UgaGF2ZSBhZ3JlZWQgdGhhdCB0aGUgZnVuZHMgd2lsbCBiZSBzaGFyZWQgdGh1cw0KYWZ0
ZXIgaXQgaGFzIGJlZW4gcGFpZCBpbnRvIHlvdXIgYWNjb3VudDoNCg0KKDEpIDMwJSBvZiB0aGUg
bW9uZXkgd2lsbCBnbyB0byB5b3UgZm9yIGFjdGluZyBhcyB0aGUNCmJlbmVmaWNpYXJ5IG9mIHRo
ZSBmdW5kLg0KKDIpIDEwJSBoYXMgYmVlbiBzZXQgYXNpZGUgYXMgYW4gYWJzdHJhY3QgcHJvamVj
dGlvbg0KZm9yIHJlaW1idXJzbWVudCB0byBib3RoIHBhcnRpZXMgZm9yIGluY2lkZW50YWwNCmV4
cGVuY2VzIHRoYXQgbWF5IGJlIGluY3VycmVkIGluIHRoZSBjb3Vyc2Ugb2YgdGhlDQp0cmFuc2Fj
dGlvbi4NCigzKSA2MCUgdG8gdXMgdGhlIGdvdmVybm1lbnQgb2ZmaWNpYWxzICh3aXRoIHdoaWNo
IHdlDQp3aXNoIHRvIGNvbW1lbmNlIGFuIGltcG9ydGF0aW9uIGJ1c2luZXNzIGluDQpjb25qdW5j
dGlvbiB3aXRoIHlvdSApLg0KIA0KQWxsIGxvZ2lzdGljcyBhcmUgaW4gcGxhY2UgYW5kIGFsbCBt
b2RhbGl0aWVzIHdvcmtlZA0Kb3V0IGZvciB0aGUgc21vb3RoIGNvbmNsdXNpb24gb2YgdGhlIHRy
YW5zYWN0aW9uIA0Kd2l0aGluIHRlbiB0byBmb3VydGVlbiBkYXlzIG9mIGNvbW1lbmNlbWVudCBh
ZnRlcg0KcmVjZWlwdCBvZiB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOiAgWW91ciBjb21wYW55
DQpuYW1lLCBhZGRyZXNzLCBjb21wYW55J3MgZGV0YWlscyAmIGFjdGl2aXRpZXMsDQp0ZWxlcGhv
bmUgJiBmYXggbnVtYmVycy4NCg0KVGhlc2UgaW5mb3JtYXRpb24gd2lsbCBlbmFibGUgdXMgbWFr
ZSB0aGUgYXBwbGljYXRpb25zDQphbmQgbG9kZ2UgY2xhaW1zIHRvIHRoZSBjb25jZXJuZWQgbWlu
aXN0cmllcyAmDQphZ2VuY2llcyBpbiBmYXZvdXIgb2YgeW91ciBjb21wYW55IGFuZCBpdCBpcyBw
ZXJ0aW5lbnQNCnRvIHN0YXRlIGhlcmUgdGhhdCB0aGlzIHRyYW5zYWN0aW9uIGlzIGVudGlyZWx5
ICBiYXNlZA0Kb24gdHJ1c3QgYXMgdGhlIHNvbGFyIGJhbmsgZHJhZnQgb3IgY2VydGlmaWVkIGNo
ZXF1ZQ0KZHJhd2FibGUgaW4gYW55IG9mIHRoZSBDZW50cmFsIEJhbmsgb2YgTmlnZXJpYQ0KY29y
cmVzcG9uZGVudCBiYW5rZXJzIGFyb3VuZCB0aGUgd29ybGQgaXMgZ29pbmcgdG8gYmUNCm1hZGUg
aW4geW91ciBuYW1lLg0KDQpsZWFzZSBhY2tub3dsZWRnZSB0aGUgcmVjZWlwdCBvZiB0aGlzIGxl
dHRlciB1c2luZyBteQ0KICAgICANCnRhdGluZyB5b3VyIHRlbC9mYXggbnVtYmVyIGZvcg0KZnVy
dGhlciBkZXRhaWxzLg0KDQpZb3VycyBmYWl0aGZ1bGx5LA0KDQpFTkdSLlRpbW15IEFsaQ0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KIA==