pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] [ pyobjc-Bugs-741782 ] Installer replaces /usr/local symlink

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

Bugs item #741782, was opened at 2003-05-22 08:00
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=741782&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Gates (p_gates)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer replaces /usr/local symlink

Initial Comment:
On my system /usr/local is a symlink to a separate device. When 
writing /usr/local/bin/nibclassbuilder, the PyObjC installer replaces 
the /usr/local symlink with a new directory. I imagine this is really a 
bug in Installer.app, but it would be great if the problem could be 
avoided or the user could be notified to check the directory.

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

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

Re: [Pyobjc-dev] Customizing trouble with NSCell & NSTableView

[Bill B. <bb...@ap...>]

On Tuesday, May 20, 2003, at 13:23 US/Pacific, Jack Jansen wrote:
> Is there any way we could catch this? The runtime system does notice 
> that it doesn't have a signature for the message it is going to be 
> calling, so it could complain (I assume). I am tempted to say that 
> calling a Python method without a signature is a bug, and we should 
> simply give an error, or are there any normal use cases of calling 
> Python methods without the signature? If so, then could we somehow 
> notify the user of this situation with a (suppressible) warning?

Given that it is generally a bad idea to create two methods with the 
same name but different signatures (different type arguments), we could 
gather all of the methods declared in informal protocols into a big 
hash (method name key, set of protocols as value).

Then, a validation step could look at all of the methods on a class and 
see if any appear in an informal protocol and a warning could be issued 
in appropriate circumstances.

This would be expensive enough that it doesn't make sense to do it all 
the time (I wouldn't think), but it would be very handy in the 
development environment.

The validation could be triggered by an NSUserDefault -- say, 
"PyObjCDebuggingEnabled" (to follow from other patterns in WebObjects 
and Cocoa -- and, as such, could be enabled by simply passing 
'-PyObjCDebuggingEnabled YES' to the app from the command line (or 
writing the value to the defaults).

b.bum

Re: [Pyobjc-dev] Customizing trouble with NSCell & NSTableView

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

I get the impression that at least everyone makes the mistake of 
forgetting to subclass from the informal protocol at least once. I 
think I already forgot it twice (and it's probably going to happen 
again:-).

Is there any way we could catch this? The runtime system does notice 
that it doesn't have a signature for the message it is going to be 
calling, so it could complain (I assume). I am tempted to say that 
calling a Python method without a signature is a bug, and we should 
simply give an error, or are there any normal use cases of calling 
Python methods without the signature? If so, then could we somehow 
notify the user of this situation with a (suppressible) warning?
--
- 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 -

Re: [Pyobjc-dev] Customizing trouble with NSCell & NSTableView

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

"Informal protocols" are effectively the set of all categories defined 
in the Framework headers where the category defines a set of methods 
that are typically used for delegation, notification, data sources, and 
other purposes where it is likely that the method is not actually 
implemented on your class's superclass (and, therefore, the signature 
will not be automatically found).

One very attractive advantage to PyObjC's implementation is that it can 
actually tell if a required method from an informal protocol has been 
implemented and will automatically warn the developer if not.

The set of informal protocols defined in Foundation.__init__ should be 
complete.

The set of informal protocols in AppKit is likely incomplete.   At 
least, I don't think it had the complete review that Foundation did.   
The following will give a [complete??] set of the various APIs that 
should likely end up as a part of an informal protocol declaration.

cd /System/Library/Frameworks/AppKit.framework/Headers/
grep '@interface NSObject' *.h

b.bum

Re: [Pyobjc-dev] Customizing trouble with NSCell & NSTableView

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

Dinu Gherman wrote:

> You made my day! I noticed a similar effect earlier on. But I wonder
> how PyObjC tells between protocols where "all" methods need to be
> implemented, like NSTableDataSource, and those where you "can" im-
> plement some of them only, like NSTableViewDelegate, but this should
> be the same for all delegate methods (not sure)...?

Use the source, Luke! Both Foundation.__init__ and AppKit.__init__
define a bunch of informal protocols. Selectors get an isRequired flag.

Just

Re: [Pyobjc-dev] Customizing trouble with NSCell & NSTableView

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

Mitch Chapman:

> The problem you describe looks like the problems I've had in creating
> an NSTableDataSource.  The solution seems to be to explicitly derive 
> your
> delegate class from  NSTableViewDelegate.

You made my day! I noticed a similar effect earlier on. But I wonder
how PyObjC tells between protocols where "all" methods need to be
implemented, like NSTableDataSource, and those where you "can" im-
plement some of them only, like NSTableViewDelegate, but this should
be the same for all delegate methods (not sure)...?

Dinu

--
Dinu C. Gherman
......................................................................
"I think if you know what you believe it makes it a lot easier
to answer questions. I can't answer your question."
(George W. Bush, 4 Oct. 2000)

Re: [Pyobjc-dev] Customizing trouble with NSCell & NSTableView

[Mitch C. <mit...@ea...>]

On Tuesday, May 20, 2003, at 06:24  AM, Dinu Gherman wrote:

> Hi,
>
> I'm trying to use NSTableView delegate method for changing the
> background of individual cells. The method name is this one:
>
>   tableView_willDisplayCell_forTableColumn_row_(self,
>     view, cell, col, row)
>
> But I always seem to receive a None value for the row argument
> and even if the method returns and does nothing else my app
> just crashes with a "signal 10 (SIGBUS)".

Hi Dinu,

The problem you describe looks like the problems I've had in creating
an NSTableDataSource.  The solution seems to be to explicitly derive 
your
delegate class from  NSTableViewDelegate.

To test I started from a Cocoa-Python application, adding an NSTableView
and wiring up the MyAppDelegate instance as the table's delegate.

The first run behaved exactly as you described.  After adding

from AppKit import NSTableViewDelegate

and

class MyAppDelegate(..., NSTableViewDelegate):

the tableView_willDisplayCell_forTableColumn_row_ method started
getting an integer for the row, rather than None; and it stopped 
crashing.


This may already be listed in the PyObjC FAQ, but it seems that, in 
general,
if you want to implement an AppKit protocol in a Python class, you must
explicitly declare that protocol as a base class of your Python class.  
Else
you get un-Pythonic segfaults and bus errors.

--
Mitch

[Pyobjc-dev] Customizing trouble with NSCell & NSTableView

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

Hi,

I'm trying to use NSTableView delegate method for changing the
background of individual cells. The method name is this one:

   tableView_willDisplayCell_forTableColumn_row_(self,
     view, cell, col, row)

But I always seem to receive a None value for the row argument
and even if the method returns and does nothing else my app
just crashes with a "signal 10 (SIGBUS)".

This book actually says, cells in default columns taken from IB
could not change their background color, and you had to replace
them in IB with new ones (p. 687), which I did, but without any
effect):

   http://www.amazon.com/exec/obidos/tg/detail/-/0672322307

Has anybody else had success using this method? The ObjC sample
provided in the book on p. 681, TableRowFormatting2, which is
also available here (chap. 18) works fine:

   http://www.cocoaprogramming.net

Might also be of interest for David Eppstein's Tabulizer code... ;-)

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Our nation must come together to unite."
(George W. Bush, 4 Jun. 2001)

Re: [Pyobjc-dev] Testsuite adventures

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

On Monday, May 19, 2003, at 14:52 Europe/Amsterdam, Dinu Gherman wrote:

> Jack Jansen:
>
>> The easy answer is that FrameWork is a very old module (I think Guido 
>> even wrote the original himself, otherwise I did many many years 
>> ago), it's a minimal application framework. It has nothing to do with 
>> MacOSX "Framework"s.
>>
>> The better answer is that this confusion is going to occur more 
>> often. Do you have any suggestions as to how I could document this? 
>> In the documentation? The help string? Anywhere else?
>
> Well, we're talking about non-portable platform-specific modules and/or
> packages, don't we? Of course, "portable" and"specific" are not always
> clearly defined or might change for a given module (say, PyObjC, once
> Apple decides to distribute Cocoa on Intel boxes).

This was discussed on python-dev (moving platform-dependent modules 
into a platform-specific package, so you would have to do "import 
mac.FrameWork" or "import win.winsound") but rejected.

Note that all platforms have specific modules (see all the plat-* 
subdirectories of Lib), it's just that the Mac has very many of them.
--
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] Best way...??

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

bb...@ma... wrote:

> [ ... ] I find being able to cmd or opt double click a method to
> go to the declaration or documentation, respectively, to be a
> tremendous boost to productivity.

How does that work for Python code?

> Also -- for the OS X solution, it is likely that you will eventually
> need to compile some code in for one reason or another.   Maybe
> performance, maybe ease of development, maybe need of accessing APIs
> that are not yet or not easily wrapped....
> 
> In that case, you will likely need to have a PBX project -- even if
> it is just a bundle project that is loaded by your pure Python
> code....

OTOH, if it's a Python extension it's probably easiest to just write a
distutils script for it (also works for .m files!).

Just

Re: [Pyobjc-dev] Best way...??

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

On Monday, May 19, 2003, at 09:09 US/Eastern, Gary Robinson wrote:
> This app is going to be a cross-platform Python app; we're using Cocoa 
> for
> the Mac interface, but will obviously use other tools for the UI for 
> other
> platforms. (I'm hoping GnuStep will work but we'll see...)
>
> So it looks like the non-PB approach is best, based on your note below.

Sorry -- I'm diving into this conversation late....

For cross platform work, I would suggest you package all the portable 
code using the standard distutils packaging tools (or something 
similar).

For the Cocoa app, PB or buildapp will both work.   PB has an advantage 
in that once the project is indexed, you have excellent integration 
with documentation for Cocoa directly into your project.  In 
particular, I find being able to cmd or opt double click a method to go 
to the declaration or documentation, respectively, to be a tremendous 
boost to productivity.

Also -- for the OS X solution, it is likely that you will eventually 
need to compile some code in for one reason or another.   Maybe 
performance, maybe ease of development, maybe need of accessing APIs 
that are not yet or not easily wrapped....

In that case, you will likely need to have a PBX project -- even if it 
is just a bundle project that is loaded by your pure Python code....

b.bum

Re: [Pyobjc-dev] Best way...??

[Gary R. <gro...@tr...>]

Thanks Jack!

This app is going to be a cross-platform Python app; we're using Cocoa for
the Mac interface, but will obviously use other tools for the UI for other
platforms. (I'm hoping GnuStep will work but we'll see...)

So it looks like the non-PB approach is best, based on your note below.

Thanks again!

--Gary

-- 
<http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] Testsuite adventures

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

Jack Jansen:

> The easy answer is that FrameWork is a very old module (I think Guido 
> even wrote the original himself, otherwise I did many many years ago), 
> it's a minimal application framework. It has nothing to do with MacOSX 
> "Framework"s.
>
> The better answer is that this confusion is going to occur more often. 
> Do you have any suggestions as to how I could document this? In the 
> documentation? The help string? Anywhere else?

Well, we're talking about non-portable platform-specific modules and/or
packages, don't we? Of course, "portable" and"specific" are not always
clearly defined or might change for a given module (say, PyObjC, once
Apple decides to distribute Cocoa on Intel boxes).

If we look into Python's standard lib. we find the os module for
which the docs have the following to say:

   This module provides a more portable way of using operating system
   dependent functionality than importing a operating system dependent
   built-in module like posix or nt. [...]
   Extensions peculiar to a particular operating system are also avail-
   able through the os module, but using them is of course a threat to
   portability!

Clearly, os is not the place for "unportable" modules. So I guess,
what we'll need sooner or later is a place or mechanism in the stan-
dard lib. to comprise non-portable code of general interest to all
users on a specific platform, maybe under "system" (still free)?

This would reduce the number of Mac-only items in the standard lib.
top level by more than 50! I just counted them on this page:

   http://www.python.org/doc/current/modindex.html

And it would be more predictable to find platform-specific stuff,
too. Of course, even then, way too general names like ColorPicker,
FrameWork, EasyDialogs and so on should have some other umbrella
package if that makes sense or be renamed to something more mean-
ing ful, probably something equivalent to Tkinter, if I understand
their purpose correctly.

> Please submit an SF bug report (for python, documentation section,
> assign to me) so I won't forget.

What bug title do you suggest? ;-)

Dinu

--
Dinu C. Gherman
......................................................................
"An error is not a mistake until you refuse to correct it."
(Werner Heisenberg)

Re: [Pyobjc-dev] Feedback needed for documentation

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

Jack Jansen:

> Wiki's simply don't work for me, and I think this is what Just also
> means, because every time I go to one that is about an interesting
> subject I have this feeling of being at a large table filled with
> beermats, postit-notes, scraps of paper and more. Clearly some of
> the people who left them there knew what they were talking about,
> but the complete lack of organization/indexing usually leaves me be-
> wildered.
> CVS and mailing lists are two CSCW paradigms that work for me, but
> Wiki's are somewhere in between, and I can't seem to get the hang
> of them.

Hi Jack!

You, too, confound people and technology! While CVS, email and wikis
are all different technologies, it doesn't mean the right people
don't exist to use them in a nasty way! (Hofstadter's argument adap-
ted: for each technology there is a set of ways to use it in a use-
less manner.) That disqualifies wikis no more than it does CVS or
email.

As you mention a lack of organization/indexing, I'll give one exam-
ple of a highly organized Wiki, with more than 120,000 articles,
Wikipedia:

   http://www.wikipedia.org
   http://www.wikipedia.org/w/wiki.phtml?search=Python
   http://www.wikipedia.org/w/wiki.phtml?search=Python&go=Go

I shall not say much more about the subject, but you can also have
dedicated bridging tools, like for coupling Wikis with CVS, so you
can work offline, too. Or take my RSS indices into CVS, which Wikis
ususally have built-in as a special page, the "RecentChanges".

Ok, for the fun of it, one more: people have built issue trackers
for wikis, like this one (clearly an example of a very organized
use of the Wiki way, isn't it? ;-)

   http://zwiki.org/IssueTracker

BTW, you can find my preliminary item collection about PyObjC do-
cumentation issues in this wiki, kindly offered by Zack. I'm not
going to work much more on it before I can have downloadable ar-
chives thereof! ;-)

   http://pyobjc.urbanape.com

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"It's difficult to make things foolproof, because fools are
so ingenious!" (Anonymous)

Re: [Pyobjc-dev] Best way...??

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

On maandag, mei 12, 2003, at 22:45 Europe/Amsterdam, Gary Robinson 
wrote:

> Hi,
>
> In the tutorial.html file, the process of creating a PyObjC app without
> Project Builder is described.
>
> In the TableModel2 example, the readme.txt file describes how to use 
> Project
> Builder, starting with creating a new "Cocoa Application" in PB.
>
> In Project Builder itself, there is a choice to create a Cocoa-Python
> application under "New...". This seems to result in a substantially
> different setup than the TableModel2 example does.
>
> Is there any technique that is "safest" in terms of using well-tested 
> code
> out of the above three? Is there a worst technique?
>
> I'd kind of like to use PB, but it's much more important to me to use
> well-tested, highly maintained code.

The choice of PB or non-PB development probably depends on two things:
1. What are you familiar with, and
2. Where is your application going to go.

If you come from an ObjC background PB is probably the best choice, if 
you come from a pure Python background non-PB is better. But if your 
app is eventually going to be rewritten in ObjC (completely or 
partially) then PB is best. And if you use PyObjC only as a quick GUI 
layer around a complex Python package that's going to be cross-platform 
(using another toolkit on non-Mac systems) then non-PB is best.

All that said, it might be a good idea to duplicate the tutorial and 
explain how to get the same end result using PB. I would be very 
interested in following that tutorial:-).

Any takers?
--
- 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 -

Re: [Pyobjc-dev] Feedback needed for documentation

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

On dinsdag, mei 13, 2003, at 11:01 Europe/Amsterdam, Dinu Gherman wrote:

> Just van Rossum:
>
>> Dunno, I'm not much of a wiki person myself (or rather: I have little
>> experience with them). If you want to contribute stuff, it's probably
>> best to post patches to the sf tracker. Even though sf is dog slow at
>> times, tracker items work pretty well for discussing single items. 
>> But:
>> if someone sets up a wiki, that would be great, too.
>
> Well, I don't know what a "Wiki person" really is. For me a tool
> either works or it doesn't. The only reason I can see for not
> using a Wiki is a bad connectivity.

Wiki's simply don't work for me, and I think this is what Just also 
means, because every time I go to one that is about an interesting 
subject I have this feeling of being at a large table filled with 
beermats, postit-notes, scraps of paper and more. Clearly some of the 
people who left them there knew what they were talking about, but the 
complete lack of organization/indexing usually leaves me bewildered.

CVS and mailing lists are two CSCW paradigms that work for me, but 
Wiki's are somewhere in between, and I can't seem to get the hang of 
them.
--
- 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 -

Re: [Pyobjc-dev] Testsuite adventures

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

On zondag, mei 18, 2003, at 16:57 Europe/Amsterdam, Dinu Gherman wrote:
>  BTW, what sense does it
> make to have a package named "FrameWork" on the Mac?

Hmm, interesting question:-)

The easy answer is that FrameWork is a very old module (I think Guido 
even wrote the original himself, otherwise I did many many years ago), 
it's a minimal application framework. It has nothing to do with MacOSX 
"Framework"s.

The better answer is that this confusion is going to occur more often. 
Do you have any suggestions as to how I could document this? In the 
documentation? The help string? Anywhere else?

Please submit an SF bug report (for python, documentation section, 
assign to me) so I won't forget.
--
- 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 -

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

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

On donderdag, mei 15, 2003, at 06:02 Europe/Amsterdam, Mitch Chapman 
wrote:

> On Wednesday, May 14, 2003, at 12:55  PM, Ronald Oussoren wrote:
>> I usually look for the right process-id from the shell and then start 
>> 'gdb /usr/local/bin/pyton THEPID' (THEPID being the process-id).
>>
>> Are you using the Project Builder templates? These use 
>> /usr/bin/python unless you change the bin-python-main.m file.
>
> Well, thanks to the in-line documentation y'all wrote in 
> bin-python-main.m,
> I wasn't having trouble figuring out which python executable to target 
> with gdb,
> or which process ID to attach to.  My problem turned out to be that I 
> wasn't  setting
> DYLD_FRAMEWORK_PATH properly,  so gdb couldn't load the Python dynamic 
> library.
>
> With DYLD_FRAMEWORK_PATH set to refer to the system frameworks 
> directory,
> like so:
> 	DYLD_FRAMEWORK_PATH=/Library/Frameworks
> gdb was happy again.

The procedure of debugging your PyObjC program with gdb should be 
documented somewhere. I always end up with adding more and more python 
debug code, even though I know that gdb would help me find the problem 
much quicker, just because I can never remember how to say the magic 
words to make gdb work on PyObjC code...
--
- 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 -

Re: [Pyobjc-dev] Testsuite adventures

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

Ronald Oussoren wrote:

> On Sunday, May 18, 2003, at 14:24 Europe/Amsterdam, Dinu Gherman
> wrote:
> >
> >>> Then, looking at Just's code I wondered where the bundebuilder
> >>> module comes from, and I'm surprised to see it in pyobjc/MPCompat
> >>> but it's installed in site-packages! This is what sort of
> >>> constantly confuses me...
> >>
> >> bundlebuilder is part of MacPython. We ship it because we use only
> >> this part of MacPython OSX.

We ship it since it doesn't ship with 2.2. (It does get installed when
you build 2.3 from source, either as framework or non-framework build.)

> > Anyway, I'm not so happy seeing too much dumped into site-packages,
> > be it by MacPython or PyObjC.
> 
> You lost me there. Where should we install if it should end up on the
> python path? bundlebuiler can be used as a program, but is primairily
> a library module.

I think it should be installed in the PyObjC folder (which is in
site-packages), for which PyObjC.pth sets the path. Somehow
bundlebuilder.py and plistlib.py end up in site-packages instead. Surely
no show-stopper...

Just

Re: [Pyobjc-dev] Testsuite adventures

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

Ronald Oussoren:

>> Anyway, I'm not so happy seeing too much dumped into site-packages,
>> be it by MacPython or PyObjC.
>
> You lost me there. Where should we install if it should end up on the 
> python path? bundlebuiler can be used as a program, but is primairily 
> a library module.

Well it says it's an OS-specific module so this is where it should
go! ;-) Like many more in the standard lib. BTW, what sense does it
make to have a package named "FrameWork" on the Mac?

OTOH, bundlebuilder isn't OS-specific because you can also use it to
"cross-build" bundles on Linux, too (taking the plistlib as well),
as I just checked (and rerun on OS X)... ;-)

Dinu

--
Dinu C. Gherman
......................................................................
"It was wonderful to find America, but it would have been more wonder-
ful to miss it." (Mark Twain)

Re: [Pyobjc-dev] Testsuite adventures

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

On Sunday, May 18, 2003, at 14:24 Europe/Amsterdam, Dinu Gherman wrote:
>
>>> Then, looking at Just's code I wondered where the bundebuilder module
>>> comes from, and I'm surprised to see it in pyobjc/MPCompat but it's
>>> installed in site-packages! This is what sort of constantly confuses
>>> me...
>>
>> bundlebuilder is part of MacPython. We ship it because we use only 
>> this part of MacPython OSX.
>
> Anyway, I'm not so happy seeing too much dumped into site-packages,
> be it by MacPython or PyObjC.

You lost me there. Where should we install if it should end up on the 
python path? bundlebuiler can be used as a program, but is primairily a 
library module.

Ronald

Re: [Pyobjc-dev] Testsuite adventures

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

Ronald Oussoren:

> There are no extensions because these are programs. I really hate it 
> when people ship executables with an extension ;-). My first thought 
> when seeing an executable with an extension (be it, '.sh', '.py' or 
> even '.exe' [on Unix!]) is that this is probably some tool used by the 
> "real" program and not something I should run.

Well, people have different thoughts and opinions, but files have ex-
tensions so a person or program can easily tell what kind of thing it
is without examining its contents. It makes writing programs easier
which operate on files/programs - as all sorts of test scripts might
be doing. Having no .py extension makes it impossible for them to im-
port such files/programs. After all, OS X programs have a .app, too.

My philosophy of turning Python scripts into more Unix-like "programs"
is to write tiny wrappers which you can put into you favourite bin/
directory, like this very short one, pp, for using ReportLab's Python-
Point program, which is contained in site-packages/reportlab:

   #! /usr/bin/env python
   import os, sys
   from reportlab.tools.pythonpoint import pythonpoint as pp
   path = sys.argv[1]
   pp.process(path, handout=0, cols=2, outDir=os.getcwd())

> You are right w.r.t. end-users running the testsuite. At the very 
> least we should add a new subcommand to setup.py (is that even 
> possible with distutils?) and/or document how to do that with the 
> source release. We should probably also distribute the runalltests 
> script, or simular functionality, with the binary distribution.

You could also test the distribution installed from a .dmg archive.

>> Then, looking at Just's code I wondered where the bundebuilder module
>> comes from, and I'm surprised to see it in pyobjc/MPCompat but it's
>> installed in site-packages! This is what sort of constantly confuses
>> me...
>
> bundlebuilder is part of MacPython. We ship it because we use only 
> this part of MacPython OSX.

Anyway, I'm not so happy seeing too much dumped into site-packages,
be it by MacPython or PyObjC.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"The proper basis for a marriage is a mutual misunderstanding."
(Oscar Wilde)

Re: [Pyobjc-dev] Testsuite adventures

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

On Sunday, May 18, 2003, at 11:41 Europe/Amsterdam, Dinu Gherman wrote:

> Ronald Oussoren:
>
>>> After this investigation I'd like to know more about what the
>>> PyObjC testing policy is? Maybe a topic for some part of the
>>> documentation?
>>
>> We try to cover as much functionality as possible with unittests.
>> We are getting closer and closer to that goal, but we are not there
>> yet.
>>
>> I regulary run the unittests using the runalltests script. I also
>> try to remember to add a unittest whenever I fix bugs, but I often
>> forget to do that.
>
> There's no doubt about that! My gut feeling is simply that the distri-
> bution might benefit from some more consistency (something I'm notori-
> ously complainging about everywhere...). The lacking extensions is
> one thing. But I'd also like users to be able to easily run the test-
> suite themselves to get this "Yippie, it's working!" feeling.

There are no extensions because these are programs. I really hate it 
when people ship executables with an extension ;-). My first thought 
when seeing an executable with an extension (be it, '.sh', '.py' or 
even '.exe' [on Unix!]) is that this is probably some tool used by the 
"real" program and not something I should run.

You are right w.r.t. end-users running the testsuite. At the very least 
we should add a new subcommand to setup.py (is that even possible with 
distutils?) and/or document how to do that with the source release. We 
should probably also distribute the runalltests script, or simular 
functionality, with the binary distribution.

>
> Then, looking at Just's code I wondered where the bundebuilder module
> comes from, and I'm surprised to see it in pyobjc/MPCompat but it's
> installed in site-packages! This is what sort of constantly confuses
> me...

bundlebuilder is part of MacPython. We ship it because we use only this 
part of MacPython OSX.
Ronald

Re: [Pyobjc-dev] Testsuite adventures

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

Ronald Oussoren:

>> After this investigation I'd like to know more about what the
>> PyObjC testing policy is? Maybe a topic for some part of the
>> documentation?
>
> We try to cover as much functionality as possible with unittests.
> We are getting closer and closer to that goal, but we are not there
> yet.
>
> I regulary run the unittests using the runalltests script. I also
> try to remember to add a unittest whenever I fix bugs, but I often
> forget to do that.

There's no doubt about that! My gut feeling is simply that the distri-
bution might benefit from some more consistency (something I'm notori-
ously complainging about everywhere...). The lacking extensions is
one thing. But I'd also like users to be able to easily run the test-
suite themselves to get this "Yippie, it's working!" feeling.

Then, looking at Just's code I wondered where the bundebuilder module
comes from, and I'm surprised to see it in pyobjc/MPCompat but it's
installed in site-packages! This is what sort of constantly confuses
me...

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Consistency is the last refuge of the unimaginative." (Oscar Wilde)

Re: [Pyobjc-dev] Just's PythonBrowser and NSOutlineView

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

Just van Rossum:

> Hm, dunno, things seem to work fine here upon brief inspection. 
> However,
> I can't guarantee you're looking at the same version as I... I attached
> my version so you can check.

Thanks! That works as expected. If you're curious I'm attaching a
patch to convert this back to what I had before...

Given the very Python-centric nature of this sample, couldn't it
become a demo included with PyObjC?

Dinu