Re: [Pyobjc-dev] re PyObjC Debuggin Best Practices

[Michael M. <mic...@gm...>]

I'm not sure if this qualifies as best practices, but I've been happy
using the PDB command line interface from within XCode.

I do use XCode, mainly to keep things separate from real work.

What I do most often is just add pdb.set_trace() where I want a
breakpoint, and re-run.
When it hits the breakpoint, I get PDB in the XCode "Debugger console"
window, and that's fine.

Like Ronald, I also use print statements often, and I've also had some
luck chasing bugs with my embedded console that I wrote to the list
about earlier. Sometimes it's nicer to just poke around in a console
that isn't the debugger.
Note that PDB doesn't currently work from inside that console.

Cheers,
-mike

On Feb 6, 2008 8:54 AM, Noah Gift <noa...@gm...> wrote:
> >>  sure I can figure out how to add the scripting to XCode as a shell
> >> script at some point.
> >
> > I don't use Xcode for Python development at all, Xcode is a nice IDE
> > for Objective-C but offers limited support for Python. When I need
> > to debug python code I tend to use print statements. That said, you
> > should be able to use your favorite Python debuggers with PyObjC
> > just like you can use them to debug wxPython programs.
>
> I would like to point out that IPython is also a very good
> alternative.  The readline stuff has been fixed, so it is quite nice
> to get tabbed completion of these huge method names.
>
>
> >
> >>
> >>
> >> I might try Eclipse are well, but I have become used to Komodo
> >> after a year or so of using it and so reluctant to tackle the
> >> Eclipse learning curve unless it offers more than Komodo. Komodo
> >> works great for wxPython debugging and I may just use wxPython
> >> instead of PyObjC for UI components. I am concerned that PyObjC is
> >> second-class on OS X just like the Java-Cocoa bridge was--and we
> >> all know how that turned out in the end. Anyone know of any
> >> commitments to do so, or is PyObjC reached its zenith given Apple
> >> is dropping other non-Cocoa things such as public Carbon-64 to
> >> focus on Cocoa?
> >
> > There are two major differences between PyObjC and the Java-Cocoa
> > bridge:
> >
> > 1) PyObjC is a straight 1-1 bridge which seriously reduces the
> > amount of work needed to add support for new APIs to PyObjC. The
> > Java-Cocoa bridge tried to map the ObjC API's to something closer to
> > Java's conventions and that required a lot of manual labor.   That's
> > one reason I've been negative about adding something simular to
> > PyObjC in the past.
> >
> > 2) PyObjC is developed outside of Apple, Java-Cocoa was a pure Apple
> > project.  This has advantages and disadvantages of course, there is
> > no risk that PyObjC will completely disappear but on the other hand
> > the development team is rather tiny (basicly just me).
> >
> > It would definitely be nice to be able to use the Xcode tools like
> > the debugger and profiler GUI's on Python scripts and I have filed
> > feature requests that asked for this.  If more people do this we
> > might even get somewhere.
> >
>
> It would be great if Apple hired Ronald and made him charge of a team
> of thousands :)
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>



-- 
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/