pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Projects and executables and stuff

[Jiva D. <ji...@de...>]

  Forgive my lack of knowledge, please see my question below:
On Dec 5, 2003, at 12:53 PM, b.bum wrote:

> A brief update of the current state of things:
>
> - Panther and Jaguar require different build styles (unless you have 
> Frameworkized Python installed)
>

  isn't the Mac  Python which ships with Panther a framework python?

--
Jiva DeVoe
jiva at devoesquared.com
http://www.devoesquared.com

[Pyobjc-dev] Projects and executables and stuff

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

A brief update of the current state of things:

- Panther and Jaguar require different build styles (unless you have 
Frameworkized Python installed)

- PBX project templates will work in Xcode, but are sub-optimal

- on Panther and forward, we no longer ever have to do the execve() 
silliness

- we really need to have a standalone bootstrap executable that can be 
plopped into the standalone buildapp.py based builds

	- as an extension, shipping a .o that could be linked could mean that 
buildapp.py could easily compile in custom Objective-C classes in the 
same fashion as distutils can now for modules.  That would absolutely 
rock in that integrating non-ObjC based C or C++ would be just a matter 
of writing an an ObjC wrapper

Re: [Pyobjc-dev] Re: Standalone exe on panther?

[Just v. R. <ju...@le...>]

Bob Ippolito wrote:

> I'm pretty sure that --semi-standalone is preferable, --standalone 
> brings no additional benefit since the 10.3 Python.framework isn't 
> compatible with 10.2.

--semi-standalone can't currently produce apps that work on both 10.2
and 10.3. --standalone apps made on 10.2 work just fine on 10.3, but not
the other way around, unless you use the Jaguar build of
Python.framework on 10.3.

Just

Re: [Pyobjc-dev] Re: Standalone exe on panther?

[Jiva D. <ji...@de...>]

In order to do this, I'd have to write my own buildapp.py script right? 
  There's nothing that would auto-generate one out of my xcode project?

On Dec 5, 2003, at 12:23 PM, David Eppstein wrote:

> In article <FD8...@de...>,
>  Jiva DeVoe <ji...@de...> wrote:
>
>> I'm documenting this here in the hopes of saving some other clueless
>> soul from similar troubles.
>>
>> So, to build a stand-alone PyObjC application do the following:
>> 	 1.  	Change your Build style to deployment. In XCode this is done by
>> going into the properties of your project and, to the styles tab, and
>> choosing deployment.
>
> The other possibility is to set up a buildapp.py script (like the ones
> that come with the pyobjc examples) and run
>     python buildapp.py --standalone build
> from the command line...
>
> -- 
> David Eppstein                      http://www.ics.uci.edu/~eppstein/
> Univ. of California, Irvine, School of Information & Computer Science
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
--
Jiva DeVoe
jiva at devoesquared.com
http://www.devoesquared.com

Re: [Pyobjc-dev] Re: Standalone exe on panther?

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

On Dec 5, 2003, at 2:23 PM, David Eppstein wrote:

> In article <FD8...@de...>,
>  Jiva DeVoe <ji...@de...> wrote:
>
>> I'm documenting this here in the hopes of saving some other clueless
>> soul from similar troubles.
>>
>> So, to build a stand-alone PyObjC application do the following:
>> 	 1.  	Change your Build style to deployment. In XCode this is done by
>> going into the properties of your project and, to the styles tab, and
>> choosing deployment.
>
> The other possibility is to set up a buildapp.py script (like the ones
> that come with the pyobjc examples) and run
>     python buildapp.py --standalone build
> from the command line...

I'm pretty sure that --semi-standalone is preferable, --standalone 
brings no additional benefit since the 10.3 Python.framework isn't 
compatible with 10.2.

-bob

[Pyobjc-dev] Re: Standalone exe on panther?

[David E. <epp...@ic...>]

In article <FD8...@de...>,
 Jiva DeVoe <ji...@de...> wrote:

> I'm documenting this here in the hopes of saving some other clueless 
> soul from similar troubles.
> 
> So, to build a stand-alone PyObjC application do the following:
> 	 1.  	Change your Build style to deployment. In XCode this is done by 
> going into the properties of your project and, to the styles tab, and 
> choosing deployment.

The other possibility is to set up a buildapp.py script (like the ones 
that come with the pyobjc examples) and run
    python buildapp.py --standalone build
from the command line...

-- 
David Eppstein                      http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

Re: [Pyobjc-dev] Standalone exe on panther?

[Jiva D. <ji...@de...>]

I'm documenting this here in the hopes of saving some other clueless 
soul from similar troubles.

So, to build a stand-alone PyObjC application do the following:
	 1.  	Change your Build style to deployment. In XCode this is done by 
going into the properties of your project and, to the styles tab, and 
choosing deployment.
	 2.  	If you originally created your application from the PyObjC 
template, inside the frameworks and modules folder in your project, you 
will find the PyObjC folder. You need to add _Foundation.so to this 
folder. This file can be found in /Library/Python/2.3/PyObjC.
	 3.  	Finally, under your target you'll find a "Copy Files" step. 
Inside there are the same files that were in the PyObjC folder in your 
frameworks above. Drag-N-Drop the _Foundation.so from there to this 
folder as well.

This should enable you to build an application which will run at the 
very least on other panther machines. It might run on Jaguar, I don't 
know for sure. There may be an easier way to do this, if you know of an 
easier way, then please let me know. The size of all this isn't too bad 
either. What's a few extra megs between friends?

I have also put this up on my blog, http://www.devoesquared.com/Blog 
for anyone who wants to track it for changes.

If this is in an FAQ somewhere, someone please point me to it.  If it's 
not, well it should be. ;)

On Dec 2, 2003, at 11:32 PM, Jiva DeVoe wrote:

> Anyone have a link to instructions on how to make a standalone pyobjc 
> exe for panther?  One that can be loaded on a stock panther machine 
> without preloading pyobjc?  I tried just building one from the xcode 
> template, and it didn't seem to work.
>
> TIA.
>
> --
> Jiva DeVoe
> jiva at devoesquared.com
> http://www.devoesquared.com
--
Jiva DeVoe
jiva at devoesquared.com
http://www.devoesquared.com

Re: [Pyobjc-dev] VTK bindings

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

On 4 dec 2003, at 12:02, Jack Jansen wrote:

>
> On 4-dec-03, at 5:39, Carlos Phillips wrote:
>>> Isn't cobject what you want here? It just gives you an opaque Python 
>>> wrapper around a C pointer, but it looks like that could be good 
>>> engouh.
>>>
>>
>> Actually you might be right. This is not ideal, but it would do. hat 
>> is this cobject? How can I use it?
>
> Cobject is part of the Python core, but it isn't very well-known (nor 
> widely used). I've always felt that it needs more support. For one 
> thing it would be really good if various (all, really) wrapper 
> packages would
> 1. Return unknown pointers as Cobjects
> 2. Allow Cobjects as initializers to any object creation method.
>
> Together these two would allow you to pass pointers back and forth 
> between extension modules that are unaware of each other. In your case 
> you would get the vtk object back as a Cobject, which you could then 
> coerce into a VTK renderer object.

It would also be pretty easy to crash the interpreter, by passing the 
wrong kind of CObject to an API :-(

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-854294 ] AutoBaseClass doesn't always bring over the right selectors

[SourceForge.net <no...@so...>]

Bugs item #854294, was opened at 2003-12-04 15:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=854294&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: AutoBaseClass doesn't always bring over the right selectors

Initial Comment:
example:
>>> from AppKit import *
>>> NSView.rectForPage_.signature
'{_NSRect={_NSPoint=ff}{_NSSize=ff}}@:i'
>>> class MyNSView(NSView):
...   def rectForPage_(self, page):
...     return ((0, 0), (0, 0))
... 
>>> MyNSView.rectForPage_.signature
'{_NSRect={_NSPoint=ff}{_NSSize=ff}}@:i'

the same "MyNSView" from an AutoBaseClass instead will 
have a rectForPage_ signature of "@@:@"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=854294&group_id=14534

[Pyobjc-dev] AFTER-HOURS TRADING - Breaking News...beyonce

[Lynn W. <ecx...@ya...>]

AFTER-HOURS TRADING - BREAKING NEWS

Get Quote - http://quote.money.cnn.com/quote/quote?symbols=3Dhtds

Hard to Treat Diseases Incorporated - HTDS - Announces: Receipt of Tuberci=
n Toxicity Study and Formation of Scientific Advisory Panel - Wednesday De=
cember 3, 8:04 pm ET 

DELRAY BEACH, Fla.--(BUSINESS WIRE)--Dec. 3, 2003--Hard to Treat Diseases =
Incorporated (Pink Sheets: HTDS) announces today that the spokesperson for=
 the independent medical group conducting the testing for HTTD (HTDS) has =
forwarded the formal Testing Results of Tubercin=AE's Toxicity Trials to H=
TTD.

Tubercin of five different concentrations was administered to five groups =
of mice. A pathologist at the University of Oklahoma Health Science Center=
 performed autopsies. The mice were randomized and only the control mouse =
was known to the pathologist, as stated in the cover letter of the Patholo=
gy Report.

The report concludes, "All tissues evaluated, visceral organs and the brai=
n were essentially normal in appearance." "The importance of this report i=
s even better than I expected," stated the spokesperson for the medical gr=
oup. "As the testing continues and if the results are similar to those of =
Chemotherapy and or radiation with no harmful side effects, Tubercin has e=
normous potential for the treatment of cancer and the immune system."

The President and CEO of HTTD, Mr. Colm J. King is in the process of formi=
ng a Scientific Advisory Panel with leading Oncologists and Immunologists =
from prestigious institutions in the U.S. The panel will review the report=
s and results of Tubercin=AE's findings and will report back to Mr. King w=
ith the ongoing reports in layman language for the shareholders.

"We are continuing to receive promising results regarding Tubercin=AE and =
we're looking forward to additional positive results in the near future," =
stated Mr. King. "These tests prove that Tubercin=AE is non-toxic and is t=
he first step on the way to human clinical trials as well as the first pos=
itive breakthrough conducted in the United States with an independent medi=
cal group for Tubercin=AE. 

Operating out of Delray Beach, Florida, Hard to Treat Diseases Incorporate=
d ("HTTD") holds the international marketing rights, except South Korea, t=
o Tubercin=AE, a patented immunostimulant developed for combating Cancer u=
nder medical patent (US Patent 6,274,356). The unique properties unlike ot=
her cancer products are clearly stated in the abstract summary of the pate=
nt... "A carbohydrate complex, which is a mixture of low molecular-weight =
polysaccharides of an arabinomannan structure extracted from Mycobacterium=
 tuberculosis, is highly effective in treating various cancer patients wit=
hout incurring any adverse side effects." 






Statements in this press release that are not historical facts are forward=
-looking statements within the meaning of the Securities Act of 1933, as a=
mended. Those statements include statements regarding the intent, belief o=
r current expectations of the Company and its management. Such statements =
reflect management's current views, are based on certain assumptions and i=
nvolve risks and uncertainties. Actual results, events, or performance may=
 differ materially from the above forward-looking statements due to a numb=
er of important factors, and will be dependent upon a variety of factors, =
including, but not limited to, our ability to obtain additional financing =
and access funds from our existing financing arrangements that will allow =
us to continue our current and future operations and whether demand for ou=
r product and testing service in domestic and international markets will c=
ontinue to expand. The Company undertakes no obligation to publicly update=
 these forward-looking statements to reflect events or circumstances that =
occur after the date hereof or to reflect any change in the Company's expe=
ctations with regard to these forward-looking statements or the occurrence=
 of unanticipated events.



























smwxhzwnjjbgzo
xybx
jysds a
mmzuadyrnk tubhe kexjsycmshnnjj

Re: [Pyobjc-dev] VTK bindings

[Jack J. <Jac...@cw...>]

On 4-dec-03, at 5:39, Carlos Phillips wrote:
>> Isn't cobject what you want here? It just gives you an opaque Python 
>> wrapper around a C pointer, but it looks like that could be good 
>> engouh.
>>
>
> Actually you might be right. This is not ideal, but it would do. hat 
> is this cobject? How can I use it?

Cobject is part of the Python core, but it isn't very well-known (nor 
widely used). I've always felt that it needs more support. For one 
thing it would be really good if various (all, really) wrapper packages 
would
1. Return unknown pointers as Cobjects
2. Allow Cobjects as initializers to any object creation method.

Together these two would allow you to pass pointers back and forth 
between extension modules that are unaware of each other. In your case 
you would get the vtk object back as a Cobject, which you could then 
coerce into a VTK renderer object.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pyobjc-dev] VTK bindings

[Carlos P. <ca...@ci...>]

On Dec 3, 2003, at 4:59 AM, Jack Jansen wrote:

>
> On 2 Dec 2003, at 18:38, Ronald Oussoren wrote:
>> The problem is that PyObjCPointer is a not really a wrapped pointer, 
>> when the PyObjCPointer object is created the value pointed-to is 
>> copied into an internal buffer. Most of the time that doesn't work, 
>> vtkRenderer is probably a C++ class and the copied value is invalid.
>>
>> I'll put creation of a real pointer wrapper on my todo-list, a 
>> generic version of the types used to wrapped some other pointer types 
>> (see pointer-support.m).
>
> Isn't cobject what you want here? It just gives you an opaque Python 
> wrapper around a C pointer, but it looks like that could be good 
> engouh.
>

Actually you might be right. This is not ideal, but it would do. hat is 
this cobject? How can I use it?

Carlos

Re: [Pyobjc-dev] VTK bindings (Modified by Carlos Phillips)

[Carlos P. <ca...@ci...>]

On Dec 3, 2003, at 6:34 AM, Carlos Phillips wrote:

> On Dec 3, 2003, at 4:59 AM, Jack Jansen wrote:
>
>>
>> On 2 Dec 2003, at 18:38, Ronald Oussoren wrote:
>>> The problem is that PyObjCPointer is a not really a wrapped pointer, 
>>> when the PyObjCPointer object is created the value pointed-to is 
>>> copied into an internal buffer. Most of the time that doesn't work, 
>>> vtkRenderer is probably a C++ class and the copied value is invalid.
>>>
>>> I'll put creation of a real pointer wrapper on my todo-list, a 
>>> generic version of the types used to wrapped some other pointer 
>>> types (see pointer-support.m).
>>
>> Isn't cobject what you want here? It just gives you an opaque Python 
>> wrapper around a C pointer, but it looks like that could be good 
>> engouh.
>
> Actually, ideally I would be able to interact with the C++ objects 
> pointed to using the already existing python wrappers. I'm not sure 
> how this could be done though.
>
> What I have are objective-c++ files containing objective-c classes 
> with methods which take and return pointers to c++ classes. VTK has 
> its own python wrappers for these c++ classes. This allows for easy 
> construction of rendering pipelines. I could wrap the c++ classes in 
> objective-c and then wrap the new objective-c classes in python 
> through PyObjC. However, this would not allow me to interact with the 
> c++ classes directly in python using VTK python classes which is what 
> I want to do.
>
> So ideally I would like to be able to see the c++ classes taken and 
> returned by my objective-c classes as VTK python wrapper objects.
>
> Example:
> An unwrapped objective-c++ class VTKView has the following method.
> -(vtkRenderer *)renderer;
>
> vtkRenderer is a c++ class. There is python wrapper class by the same 
> name. I would like to wrap and/or alter VTKView so that I can do the 
> following in Python:
>
> v = VTKView.alloc().init()
> v.renderer().AddActor(...)
>
> or be able to use v.renderer() as an argument to some python wrapped 
> VTK method.

Actually, if I can't do this, I would settle for simply hiding the c++ 
pointer attributes and c++ related methods from PyObjC. Can I do that?

Carlos

[Pyobjc-dev] [ pyobjc-Bugs-853553 ] Path error in PyObjC tutorial

[SourceForge.net <no...@so...>]

Bugs item #853553, was opened at 2003-12-03 12:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=853553&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Path error in PyObjC tutorial

Initial Comment:
In step 6 under "Testing the User Interface", the tutorial 
states:

If you are using Python 2.3 the script is located in plat-mac 
instead of site-packages and the command is:

$ python2.3 $PYLIB/plat-mac/PyObjC/bundlebuilder.py --link 
--nib=MainMenu         --mainprogram=CurrencyConverter.py --
resource=MainMenu.nib build


"PyObjC" needs to be removed from the path. In python 2.3, 
bundlebuilder.py is in the plat-mac directory and not in the 
subdirectory "PyObjC".



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=853553&group_id=14534

Re: [Pyobjc-dev] VTK bindings

[Carlos P. <ca...@ci...>]

On Dec 3, 2003, at 4:59 AM, Jack Jansen wrote:

>
> On 2 Dec 2003, at 18:38, Ronald Oussoren wrote:
>> The problem is that PyObjCPointer is a not really a wrapped pointer, 
>> when the PyObjCPointer object is created the value pointed-to is 
>> copied into an internal buffer. Most of the time that doesn't work, 
>> vtkRenderer is probably a C++ class and the copied value is invalid.
>>
>> I'll put creation of a real pointer wrapper on my todo-list, a 
>> generic version of the types used to wrapped some other pointer types 
>> (see pointer-support.m).
>
> Isn't cobject what you want here? It just gives you an opaque Python 
> wrapper around a C pointer, but it looks like that could be good 
> engouh.

Actually, ideally I would be able to interact with the C++ objects 
pointed to using the already existing python wrappers. I'm not sure how 
this could be done though.

What I have are objective-c++ files containing objective-c classes with 
methods which take and return pointers to c++ classes. VTK has its own 
python wrappers for these c++ classes. This allows for easy 
construction of rendering pipelines. I could wrap the c++ classes in 
objective-c and then wrap the new objective-c classes in python through 
PyObjC. However, this would not allow me to interact with the c++ 
classes directly in python using VTK python classes which is what I 
want to do.

So ideally I would like to be able to see the c++ classes taken and 
returned by my objective-c classes as VTK python wrapper objects.

Example:
An unwrapped objective-c++ class VTKView has the following method.
-(vtkRenderer *)renderer;

vtkRenderer is a c++ class. There is python wrapper class by the same 
name. I would like to wrap and/or alter VTKView so that I can do the 
following in Python:

v = VTKView.alloc().init()
v.renderer().AddActor(...)

or be able to use v.renderer() as an argument to some python wrapped 
VTK method.

Re: [Pyobjc-dev] VTK bindings

[Jack J. <Jac...@cw...>]

On 2 Dec 2003, at 18:38, Ronald Oussoren wrote:
> The problem is that PyObjCPointer is a not really a wrapped pointer, 
> when the PyObjCPointer object is created the value pointed-to is 
> copied into an internal buffer. Most of the time that doesn't work, 
> vtkRenderer is probably a C++ class and the copied value is invalid.
>
> I'll put creation of a real pointer wrapper on my todo-list, a generic 
> version of the types used to wrapped some other pointer types (see 
> pointer-support.m).

Isn't cobject what you want here? It just gives you an opaque Python 
wrapper around a C pointer, but it looks like that could be good 
engouh.
--
Jack Jansen        <Jac...@cw...>        http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

[Pyobjc-dev] Standalone exe on panther?

[Jiva D. <ji...@de...>]

Anyone have a link to instructions on how to make a standalone pyobjc 
exe for panther?  One that can be loaded on a stock panther machine 
without preloading pyobjc?  I tried just building one from the xcode 
template, and it didn't seem to work.

TIA.

--
Jiva DeVoe
jiva at devoesquared.com
http://www.devoesquared.com

Re: [Pyobjc-dev] VTK bindings

[Carlos P. <ca...@ci...>]

On Dec 2, 2003, at 1:13 PM, Bob Ippolito wrote:

>
> On Dec 2, 2003, at 12:38 PM, Ronald Oussoren wrote:
>
>>
>> On 2 dec 2003, at 16:23, b.bum wrote:
>>
>>> On Dec 2, 2003, at 1:12 AM, Carlos Phillips wrote:
>>>> 2003-12-02 03:30:46.165 Simple1[1541] PyObjCPointer created: at  
>>>> 0x6d16080 of type  
>>>> {vtkRenderer={?={?={?=^^?i}C{vtkTimeStamp=^^? 
>>>> L}^{vtkSubjectHelper}}^{vtkAssemblyPath}^{vtkPropCollection}iIff^{vt 
>>>> kPropCollection}^{vtkActor2DCollection}^{vtkWindow}[3f][4f][2f][2f][ 
>>>> 2f][2i][2i][3f][3f][4f]}^{vtkCamera}^{vtkLight}^{vtkLightCollection} 
>>>> ^{vtkCullerCollection}^{vtkActorCollection}^{vtkVolumeCollection}[3f 
>>>> ]^{vtkRenderWindow}ffiii*{vtkTimeStamp=^^? 
>>>> L}fii^^{vtkProp}i^^{vtkAssemblyPath}iii[6f]f}8@0:4
>>>
>>> Like Bob said, once a PyObjCPointer is created, you are generally  
>>> out of luck.  PyObjC transparently bridged Objective-C.  In this  
>>> case, you are asking it to transparently bridge a relatively complex  
>>> C data type.
>>
>> The problem is that PyObjCPointer is a not really a wrapped pointer,  
>> when the PyObjCPointer object is created the value pointed-to is  
>> copied into an internal buffer. Most of the time that doesn't work,  
>> vtkRenderer is probably a C++ class and the copied value is invalid.
>>
>> I'll put creation of a real pointer wrapper on my todo-list, a  
>> generic version of the types used to wrapped some other pointer types  
>> (see pointer-support.m).
>>
>> Is VTK itself wrapped? If so, you could use the functions in  
>> pointer-support.m to convert vtkRenderer* to the Python wrapper from  
>> the VTK wrapper.
>
> VTK itself does have python wrappers.. they probably work on OS X by  
> now, but there were problems last time I tried (a long while ago, due  
> to linking issues).
>
> -bob

The VTK python wrapper now works quite well. In fact I have quite a bit  
of python VTK code which runs from the command line. I looked through  
pointer-support.m but was unable to determine how I should use it to  
leverage this fact. All the C++ classes which show up in the interface  
have a wrapped python equivalent.

Carlos

Re: [Pyobjc-dev] Subclassing from NibClassBuilder-generated files

[Jordan K. <jo...@kr...>]

On 2-Dec-03, at 1:11 PM, Martina Oefelein wrote:

> This doesn't rename the ObjC class 'Converter'. (Actually, AFAIK it 
> doesn't rename the python class either, it only makes the class 
> available under a new nickname)

Yep.

> You are trying to create a new class Converter, which inherits from 
> the existing Python/objc class Converter. Thus PyObjC tries to make 
> the new Python class also known to the objc runtime, but this fails 
> due the name conflict with the existing class:
>
>> objc.error: Class already exists in Objective-C runtime
>
> Contrary to Python classes, objc classes don't live in modules. On the 
> objc side, all classes live in a single namespace. 
> CurrencyConverter.Converter (also known as t._Converter) and 
> t.Converter would both map to the same objc class Converter.

Gotcha.  That's the part I was forgetting (haven't written any C-like 
stuff in years.. one gets spoiled).

> If you just added one or two new actions in IB, it is probably not 
> worth to go re-run, you can just type in the new method name(s) by 
> hand.
>
> If you made a lot of changes in IB, re-running NibClassBuilder may 
> save some typing. For example, just let NibClassBuilder write the 
> class to stdout, and copy the new declarations from the terminal 
> window into your script.
>
> Note that the technique which you described wouldn't save you the 
> typing/copying, either (if it would work). You would have to type/copy 
> the same action names into your subclass...

Yes, I just was trying to think of a non-lossy way to make changes in 
IB; having to add code for new stuff created in IB was a given, I just 
wasn't sure what else IB could affect, aside from outlets/actions.  
That's why I figured I'd ask here, 'cause every set of tools is used 
differently.

Thanks!  I guess I'll just keep on working as-is, and see what I come 
up with.

J.

Re: [Pyobjc-dev] Subclassing from NibClassBuilder-generated files

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

Hi Jordan,

> I tried creating another file for CurrencyConverter which imported 
> CurrencyConverter.py's classes (which were renamed to _Converter and 
> _ConverterController), subclassed them,  and attempted to call 
> runEventLoop() from there, but the runtime is complaining that the 
> classes already exist:
>
>   File "Resources/t.py", line 6, in ?
>     class Converter(_Converter):
> objc.error: Class already exists in Objective-C runtime
>
> Here's t.py:
>
> *snip*
> from PyObjCTools import NibClassBuilder, AppHelper
>
> from CurrencyConverter import Converter as _Converter

This doesn't rename the ObjC class 'Converter'. (Actually, AFAIK it 
doesn't rename the python class either, it only makes the class 
available under a new nickname)

> class Converter(_Converter):
>         pass

You are trying to create a new class Converter, which inherits from the 
existing Python/objc class Converter. Thus PyObjC tries to make the new 
Python class also known to the objc runtime, but this fails due the 
name conflict with the existing class:

> objc.error: Class already exists in Objective-C runtime

Contrary to Python classes, objc classes don't live in modules. On the 
objc side, all classes live in a single namespace. 
CurrencyConverter.Converter (also known as t._Converter) and 
t.Converter would both map to the same objc class Converter.

> If this is in fact a problem, how does one get around this?  Perhaps 
> I'm just used to wxglade, where it exports classes to be used 
> elsewhere, knowing that they will be generated often.  If it's 
> something else, please let me know :)

You don't need to re-run NibClassBuilder as a script after changing the 
nib. Usually you run it once to create a template from which you can 
work on, to save some typing.

If you just added one or two new actions in IB, it is probably not 
worth to go re-run, you can just type in the new method name(s) by 
hand.

If you made a lot of changes in IB, re-running NibClassBuilder may save 
some typing. For example, just let NibClassBuilder write the class to 
stdout, and copy the new declarations from the terminal window into 
your script.

Note that the technique which you described wouldn't save you the 
typing/copying, either (if it would work). You would have to type/copy 
the same action names into your subclass...

ciao
Martina

Re: [Pyobjc-dev] Subclassing from NibClassBuilder-generated files

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

On 2 dec 2003, at 1:40, Jordan Krushen wrote:

> Going through the tutorial and other examples, I'm wondering why the 
> (implied) common practice is to directly edit the 
> NibClassBuilder-generated python files.  Will regeneration upon 
> changes in IB destroy changes to the file?

Regeneration would destroy changes to the file, that's why we never 
regenerate the file :-).
The generated file doesnt' contain code that cannot be easily typed 
into it, you only have to add methods that implement the actions and 
that can easily done by hand.


>
> I tried creating another file for CurrencyConverter which imported 
> CurrencyConverter.py's classes (which were renamed to _Converter and 
> _ConverterController), subclassed them,  and attempted to call 
> runEventLoop() from there, but the runtime is complaining that the 
> classes already exist:
>
>   File "Resources/t.py", line 6, in ?
>     class Converter(_Converter):
> objc.error: Class already exists in Objective-C runtime

In Objective-C, and therefore also in PyObjC, classnames must be unique 
across your entire program (including linked frameworks/libraries). 
That's why renaming doesn't work.

> If this is in fact a problem, how does one get around this?  Perhaps 
> I'm just used to wxglade, where it exports classes to be used 
> elsewhere, knowing that they will be generated often.  If it's 
> something else, please let me know :)

I usually generate the file once and update it by hand later on, often 
I don't bother with generating the first generation file and create it 
manually as well.

I don't know wxglade but at least some code-generation tools used to 
create files that contained the actual code for building the widgets. 
The files generated by nibclassbuilder only contain the placeholders 
for the methods that implement the application logic, the NIB file 
contains a 'pickled' version of the actual widgets.

Ronald

Re: [Pyobjc-dev] VTK bindings

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

On Dec 2, 2003, at 12:38 PM, Ronald Oussoren wrote:

>
> On 2 dec 2003, at 16:23, b.bum wrote:
>
>> On Dec 2, 2003, at 1:12 AM, Carlos Phillips wrote:
>>> 2003-12-02 03:30:46.165 Simple1[1541] PyObjCPointer created: at  
>>> 0x6d16080 of type  
>>> {vtkRenderer={?={?={?=^^?i}C{vtkTimeStamp=^^? 
>>> L}^{vtkSubjectHelper}}^{vtkAssemblyPath}^{vtkPropCollection}iIff^{vtk 
>>> PropCollection}^{vtkActor2DCollection}^{vtkWindow}[3f][4f][2f][2f][2f 
>>> ][2i][2i][3f][3f][4f]}^{vtkCamera}^{vtkLight}^{vtkLightCollection}^{v 
>>> tkCullerCollection}^{vtkActorCollection}^{vtkVolumeCollection}[3f]^{v 
>>> tkRenderWindow}ffiii*{vtkTimeStamp=^^? 
>>> L}fii^^{vtkProp}i^^{vtkAssemblyPath}iii[6f]f}8@0:4
>>
>> Like Bob said, once a PyObjCPointer is created, you are generally out  
>> of luck.  PyObjC transparently bridged Objective-C.  In this case,  
>> you are asking it to transparently bridge a relatively complex C data  
>> type.
>
> The problem is that PyObjCPointer is a not really a wrapped pointer,  
> when the PyObjCPointer object is created the value pointed-to is  
> copied into an internal buffer. Most of the time that doesn't work,  
> vtkRenderer is probably a C++ class and the copied value is invalid.
>
> I'll put creation of a real pointer wrapper on my todo-list, a generic  
> version of the types used to wrapped some other pointer types (see  
> pointer-support.m).
>
> Is VTK itself wrapped? If so, you could use the functions in  
> pointer-support.m to convert vtkRenderer* to the Python wrapper from  
> the VTK wrapper.

VTK itself does have python wrappers.. they probably work on OS X by  
now, but there were problems last time I tried (a long while ago, due  
to linking issues).

-bob

Re: [Pyobjc-dev] VTK bindings

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

On 2 dec 2003, at 16:23, b.bum wrote:

> On Dec 2, 2003, at 1:12 AM, Carlos Phillips wrote:
>> 2003-12-02 03:30:46.165 Simple1[1541] PyObjCPointer created: at  
>> 0x6d16080 of type  
>> {vtkRenderer={?={?={?=^^?i}C{vtkTimeStamp=^^? 
>> L}^{vtkSubjectHelper}}^{vtkAssemblyPath}^{vtkPropCollection}iIff^{vtkP 
>> ropCollection}^{vtkActor2DCollection}^{vtkWindow}[3f][4f][2f][2f][2f][ 
>> 2i][2i][3f][3f][4f]}^{vtkCamera}^{vtkLight}^{vtkLightCollection}^{vtkC 
>> ullerCollection}^{vtkActorCollection}^{vtkVolumeCollection}[3f]^{vtkRe 
>> nderWindow}ffiii*{vtkTimeStamp=^^? 
>> L}fii^^{vtkProp}i^^{vtkAssemblyPath}iii[6f]f}8@0:4
>
> Like Bob said, once a PyObjCPointer is created, you are generally out  
> of luck.  PyObjC transparently bridged Objective-C.  In this case, you  
> are asking it to transparently bridge a relatively complex C data  
> type.

The problem is that PyObjCPointer is a not really a wrapped pointer,  
when the PyObjCPointer object is created the value pointed-to is copied  
into an internal buffer. Most of the time that doesn't work,  
vtkRenderer is probably a C++ class and the copied value is invalid.

I'll put creation of a real pointer wrapper on my todo-list, a generic  
version of the types used to wrapped some other pointer types (see  
pointer-support.m).

Is VTK itself wrapped? If so, you could use the functions in  
pointer-support.m to convert vtkRenderer* to the Python wrapper from  
the VTK wrapper.

Ronald

Re: [Pyobjc-dev] VTK bindings

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

On Dec 2, 2003, at 1:12 AM, Carlos Phillips wrote:
> 2003-12-02 03:30:46.165 Simple1[1541] PyObjCPointer created: at  
> 0x6d16080 of type  
> {vtkRenderer={?={?={?=^^?i}C{vtkTimeStamp=^^? 
> L}^{vtkSubjectHelper}}^{vtkAssemblyPath}^{vtkPropCollection}iIff^{vtkPr 
> opCollection}^{vtkActor2DCollection}^{vtkWindow}[3f][4f][2f][2f][2f][2i 
> ][2i][3f][3f][4f]}^{vtkCamera}^{vtkLight}^{vtkLightCollection}^{vtkCull 
> erCollection}^{vtkActorCollection}^{vtkVolumeCollection}[3f]^{vtkRender 
> Window}ffiii*{vtkTimeStamp=^^? 
> L}fii^^{vtkProp}i^^{vtkAssemblyPath}iii[6f]f}8@0:4

Like Bob said, once a PyObjCPointer is created, you are generally out  
of luck.  PyObjC transparently bridged Objective-C.  In this case, you  
are asking it to transparently bridge a relatively complex C data type.

Having had a look at the article, I see three methods like this....

-(vtkRenderer *)renderer;
-(vtkRenderWindow *)renderWindow;
-(vtkRenderWindowInteractor *)renderWindowInteractor;

... invoking the first would cause the above message to be produced.

The problem is that you are passing a C structure reference across the  
bridge into the Python world.   This is an edge case that is generally  
hard to handle.

One solution would be to create a class for each c structure.  Then,  
implement a method that returns an instance of the class that contains  
the structure.  Each class would have instance methods that would  
get/set the data found within the C structure-- the vtkRenderer *, for  
example.

b.bum

Re: [Pyobjc-dev] VTK bindings

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

On Dec 2, 2003, at 4:12 AM, Carlos Phillips wrote:

> I'm trying to create a python-cocoa program with a VTK view. The VTK  
> view is taken verbatim from the two articles on MacDevCenter (link  
> follows) which is written in objective-c.
>
> http://www.macdevcenter.com/pub/a/mac/2003/02/11/dev_osx.html
> http://www.macdevcenter.com/pub/a/mac/2003/03/25/dev_osx.html
>
> I am using an up-to-date CVS version of PyObjC. I have created a  
> project using the Cocoa-Python-ObjC template. I have placed the two  
> objective-c classes involved in the VTK view into the support  
> framework. I also have put renamed copies of the VTK cocoa objective-c  
> classes in this framework. This allows me to wrap the VTK view class  
> using objc.loadBundle.
>
> I have subclassed VTKView in python to emulate the program written in  
> the second macdevcenter article and instantiated it through the  
> MainMenu.nib.
>
> When I run the program, it crashes. It's log output is:
> =====
> 2003-12-02 03:30:46.165 Simple1[1541] PyObjCPointer created: at  
> 0x6d16080 of type  
> {vtkRenderer={?={?={?=^^?i}C{vtkTimeStamp=^^? 
> L}^{vtkSubjectHelper}}^{vtkAssemblyPath}^{vtkPropCollection}iIff^{vtkPr 
> opCollection}^{vtkActor2DCollection}^{vtkWindow}[3f][4f][2f][2f][2f][2i 
> ][2i][3f][3f][4f]}^{vtkCamera}^{vtkLight}^{vtkLightCollection}^{vtkCull 
> erCollection}^{vtkActorCollection}^{vtkVolumeCollection}[3f]^{vtkRender 
> Window}ffiii*{vtkTimeStamp=^^? 
> L}fii^^{vtkProp}i^^{vtkAssemblyPath}iii[6f]f}8@0:4
>
> Simple1 has exited due to signal 10 (SIGBUS).
> =====
>
> The Debugger complains that here is a lack of stack frames:
> =====
> warning: Trying to remove a section from the ordered section list that  
> did not exist at 0x0.
> Program received signal:  "SIGTRAP".
> warning: ppc_frame_chain_valid: stack pointer from 0xbffff84c to  
> 0x1000 grows upward; assuming invalid
>
> mi_cmd_stack_list_frames: Not enough frames in stack.
> mi_cmd_stack_list_frames: Not enough frames in stack.
> =====
>
> Does anyone know what is going on? I know that quite a few people  
> would be happy if they could integrate VTK views into cocoa programs  
> using python and interface builder.

When a PyObjCPointer is created, that means that some type came across  
the bridge that PyObjC has no idea how to handle, which causes a crash  
almost all the time.  I have no idea about the stack frame business,  
but as soon as you see PyObjCPointer you might as well have crashed.

If you post the exact source code you are using then I'll help you  
further (I don't know what selector is causing that message in your  
example), but you should read  
http://pyobjc.sourceforge.net/doc/wrapping.php  If it can't be done  
properly by signature alone for whatever reason, then you have to write  
ObjC code to wrap that selector.

-bob