Thread: [Pyobjc-dev] cvs snapshots?

Brought to you by: ronaldoussoren

pyobjc-dev

[Pyobjc-dev] cvs snapshots?

From: Michael H. <mw...@py...> - 2003-07-01 18:08:58

Given SF's current attitude to anon CVS, is it possible to make
available snapshots of the state of CVS semi-regularly?

Cheers,
M.

-- 
  ARTHUR:  Don't ask me how it works or I'll start to whimper.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11

Re: [Pyobjc-dev] cvs snapshots?

From: Bob I. <bo...@re...> - 2003-07-01 18:38:24

On Tuesday, Jul 1, 2003, at 13:43 America/New_York, Michael Hudson 
wrote:

> Given SF's current attitude to anon CVS, is it possible to make
> available snapshots of the state of CVS semi-regularly?

SF *should* already do this, a nightly tarball sits at a url like this: 
  http://cvs.sourceforge.net/cvstarballs/pyobjc-cvsroot.tar.gz (I can't 
verify the accuracy of this because SF is not responding at all for me 
right now).

However, I think that this is the actual repository, not a checkout..

-bob

Re: [Pyobjc-dev] cvs snapshots?

From: Just v. R. <ju...@le...> - 2003-07-01 19:05:07

Bob Ippolito wrote:

> > Given SF's current attitude to anon CVS, is it possible to make
> > available snapshots of the state of CVS semi-regularly?
> 
> SF *should* already do this, a nightly tarball sits at a url like
> this: http://cvs.sourceforge.net/cvstarballs/pyobjc-cvsroot.tar.gz (I
> can't verify the accuracy of this because SF is not responding at all
> for me right now).
> 
> However, I think that this is the actual repository, not a checkout..

I'm pretty sure it's indeed the repository...

For my fonttools.sf project I use a (found) Python script that does a
checkout and builds tarballs. It's a nightly cron job. However, I'm
pretty sure it does an anon pserver checkout, so it probably suffers the
same problems. Hm. It would still be useful for people not comfortable
with CVS, though.

Just

Re: [Pyobjc-dev] cvs snapshots?

From: b.bum <bb...@ma...> - 2003-07-01 22:45:50

On Tuesday, July 1, 2003, at 2:49 PM, Just van Rossum wrote:
> For my fonttools.sf project I use a (found) Python script that does a
> checkout and builds tarballs. It's a nightly cron job. However, I'm
> pretty sure it does an anon pserver checkout, so it probably suffers 
> the
> same problems. Hm. It would still be useful for people not comfortable
> with CVS, though.

Could we use the build servers to good effect here?

b.bum

Re: [Pyobjc-dev] cvs snapshots?

From: Just v. R. <ju...@le...> - 2003-07-02 08:42:26

b.bum wrote:

> On Tuesday, July 1, 2003, at 2:49 PM, Just van Rossum wrote:
> > For my fonttools.sf project I use a (found) Python script that does
> > a checkout and builds tarballs. It's a nightly cron job. However,
> > I'm pretty sure it does an anon pserver checkout, so it probably
> > suffers the same problems. Hm. It would still be useful for people
> > not comfortable with CVS, though.
> 
> Could we use the build servers to good effect here?

I run it on a regular shell server at sf.

I thought it would be trivial to get it running for pyobjc as well, but
it turned out the script contained a bug that caused it to fail as soon
as there are folders with spaces in their names. I managed to fix that,
though, and now I have a nightly cron job running, outputting stuff at

  http://pyobjc.sourceforge.net/cvs-snapshots/

Please wait with advertizing it on the site until we're absolutely sure
things work correctly.

Just

[Pyobjc-dev] Re: cvs snapshots?

From: Michael H. <mw...@py...> - 2003-07-02 13:17:50

Just van Rossum <ju...@le...> writes:

> b.bum wrote:
>
>> On Tuesday, July 1, 2003, at 2:49 PM, Just van Rossum wrote:
>> > For my fonttools.sf project I use a (found) Python script that does
>> > a checkout and builds tarballs. It's a nightly cron job. However,
>> > I'm pretty sure it does an anon pserver checkout, so it probably
>> > suffers the same problems. Hm. It would still be useful for people
>> > not comfortable with CVS, though.
>> 
>> Could we use the build servers to good effect here?
>
> I run it on a regular shell server at sf.
>
> I thought it would be trivial to get it running for pyobjc as well, but
> it turned out the script contained a bug that caused it to fail as soon
> as there are folders with spaces in their names. I managed to fix that,
> though, and now I have a nightly cron job running, outputting stuff at
>
>   http://pyobjc.sourceforge.net/cvs-snapshots/
>
> Please wait with advertizing it on the site until we're absolutely sure
> things work correctly.

I get a bunch of these:

tar: Unable to create pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python Application/English.lproj/MainMenu.nib/ <Is a directory>

when unpacking... but using 'gnutar' works.  Would guess this is the
recently-mentioned on python-dev tar problem...

Cheers,
M.

-- 
  Famous remarks are very seldom quoted correctly.
                                                    -- Simeon Strunsky

Re: [Pyobjc-dev] Re: cvs snapshots?

From: Just v. R. <ju...@le...> - 2003-07-02 14:01:10

Michael Hudson wrote:

> I get a bunch of these:
> 
> tar: Unable to create pyobjc/ProjectBuilder Extras/Project
> Templates/Cocoa-Python Application/English.lproj/MainMenu.nib/ <Is a
> directory>

Hm, I rather get messages like

pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
Application/CocoaApp.pbproj/CVS/Entries
././@LongLink
pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
Application/CocoaApp.pbproj/TemplateInf
././@LongLink

> when unpacking... but using 'gnutar' works.  Would guess this is the
> recently-mentioned on python-dev tar problem...

Sounds like it. Btw. StuffIt Expander also extracts the files correctly.

(Btw. I also dislike the spaces in the folder names; our checkin
messages script doesn't like these, or at least I never see diffs of
files inside those folders.)

Just

Re: [Pyobjc-dev] Re: cvs snapshots?

From: Jack J. <Jac...@cw...> - 2003-07-02 15:13:25

On Wednesday, Jul 2, 2003, at 16:00 Europe/Amsterdam, Just van Rossum 
wrote:

> Michael Hudson wrote:
>
>> I get a bunch of these:
>>
>> tar: Unable to create pyobjc/ProjectBuilder Extras/Project
>> Templates/Cocoa-Python Application/English.lproj/MainMenu.nib/ <Is a
>> directory>
>
> Hm, I rather get messages like
>
> pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
> Application/CocoaApp.pbproj/CVS/Entries
> ././@LongLink
> pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
> Application/CocoaApp.pbproj/TemplateInf
> ././@LongLink

I think the problem here is that gnutar and OSX-tar are not 100% 
compatible.
To make matters worse, once you use fink it will install a GNU tar in 
/sw/bin
with the name "tar", and it obscures OSX tar. The result of this is 
that you
create tarfiles that cannot be read by people who have only a basic OSX
installation. I got bitten by this a while ago.

And if you remove /sw/bin/tar (keeping /sw/bin/gnutar) the next time 
you run
fink it will happily install it again:-(
--
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] Re: cvs snapshots?

From: Just v. R. <ju...@le...> - 2003-07-02 15:17:14

Jack Jansen wrote:

> I think the problem here is that gnutar and OSX-tar are not 100%
> compatible. To make matters worse, once you use fink it will install
> a GNU tar in 
> /sw/bin
> with the name "tar", and it obscures OSX tar. The result of this is
> that you create tarfiles that cannot be read by people who have only
> a basic OSX installation. I got bitten by this a while ago.

Note that the snapshot tar files are created on a Linux shell box @ sf,
but I have no idea what tar version that is.

Just

[Pyobjc-dev] Re: cvs snapshots?

From: Michael H. <mw...@py...> - 2003-07-03 10:26:54

Just van Rossum <ju...@le...> writes:

> Jack Jansen wrote:
>
>> I think the problem here is that gnutar and OSX-tar are not 100%
>> compatible. To make matters worse, once you use fink it will install
>> a GNU tar in 
>> /sw/bin
>> with the name "tar", and it obscures OSX tar. The result of this is
>> that you create tarfiles that cannot be read by people who have only
>> a basic OSX installation. I got bitten by this a while ago.

Although I still have bits of fink installed, I removed /sw/bin from
my path for exactly this sort of reason (in general I wish fink worked
more with the BSD tools as present in OS X rather than trying to slap
a GNU/Darwin system on top, but I guess this isn't the place for that
rant).

> Note that the snapshot tar files are created on a Linux shell box @ sf,
> but I have no idea what tar version that is.

It'll be GNU tar, no question.

Cheers,
M.

-- 
  Need to Know is usually an interesting UK digest of things that
  happened last week or might happen next week. [...] This week,
  nothing happened, and we don't care.
                           -- NTK Now, 2000-12-29, http://www.ntk.net/

[Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Bill D. <wdd...@ma...> - 2003-07-05 18:43:12

Hi All,

bin-python-main.m  does not compile. There are errors due to variables 
not being declared early enough.

Does this code compile for anyone else? I'd love to be able to declare 
variables later, C++ style, if obj-c can allow it.

Thanks.

Re: [Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Ronald O. <ous...@ci...> - 2003-07-05 19:27:59

On Saturday, 5 July, 2003, at 20:43, Bill Dozier wrote:

> Hi All,
>
> bin-python-main.m  does not compile. There are errors due to variables 
> not being declared early enough.
>
> Does this code compile for anyone else? I'd love to be able to declare 
> variables later, C++ style, if obj-c can allow it.

What compiler are you using? The default compiler on OSX 10.2 should be 
gcc 3.1, and that allows "C++ style" declarations, GCC 2.95 doesn't. 
You can check the default compiler using 'gcc_select'.

Ronald

Re: [Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Bill D. <wdd...@ma...> - 2003-07-05 19:38:29

Ronald,

this is confusing:

[gigabook:~/build/pyobjc-1.0b1] daddy% which gcc
/usr/bin/gcc
[gigabook:~/build/pyobjc-1.0b1] daddy% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
[gigabook:~/build/pyobjc-1.0b1] daddy%
[gigabook:~/build/pyobjc-1.0b1] daddy% gcc_select
Current default compiler:
gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
[gigabook:~/build/pyobjc-1.0b1] daddy%


However, PB only gives 2.95 and 3.1 as choices (3.1 is selected).

In the build window, though:

/Developer/Private/jam -d1 -j1  
JAMBASE=/Developer/Makefiles/pbx_jamfiles/ProjectBuilderJambase  
JAMFILE=- build ACTION=build _DEFAULT_GCC_VERSION=2.95.2  
BUILD_STYLE=Development  
CPP_HEADERMAP_FILE=/Users/daddy/Desktop/pydoctest/build/ 
pydoctest.build/pydoctest.build/pydoctest.hmap  
SRCROOT=/Users/daddy/Desktop/pydoctest  
OBJROOT=/Users/daddy/Desktop/pydoctest/build  
SYMROOT=/Users/daddy/Desktop/pydoctest/build DSTROOT=/tmp/pydoctest.dst

...

BuildPhase <CopyResources>pydoctest.app

CompileC  
/Users/daddy/Desktop/pydoctest/build/pydoctest.build/pydoctest.build/ 
Objects-normal/ppc/bin-python-main.o
     /usr/bin/gcc2  -c -F/Users/daddy/Desktop/pydoctest/build   
-I/Users/daddy/Desktop/pydoctest/build/include  -arch ppc -fno-common  
-fpascal-strings -O0 -Wmost -Wno-four-char-constants  
-Wno-unknown-pragmas -pipe -g -precomp-trustfile  
/Users/daddy/Desktop/pydoctest/build/pydoctest.build/pydoctest.build/ 
TrustedPrecomps.txt  
-Wp,-header-mapfile,/Users/daddy/Desktop/pydoctest/build/ 
pydoctest.build/pydoctest.build/pydoctest.hmap       bin-python-main.m   
-o  
/Users/daddy/Desktop/pydoctest/build/pydoctest.build/pydoctest.build/ 
Objects-normal/ppc/bin-python-main.o


I am neither a PB nor a jam expert.  Where is _DEFAULT_GCC_VERSION set?

Thanks,
Bill


On Saturday, July 5, 2003, at 02:26 PM, Ronald Oussoren wrote:

>
> On Saturday, 5 July, 2003, at 20:43, Bill Dozier wrote:
>
>> Hi All,
>>
>> bin-python-main.m  does not compile. There are errors due to  
>> variables not being declared early enough.
>>
>> Does this code compile for anyone else? I'd love to be able to  
>> declare variables later, C++ style, if obj-c can allow it.
>
> What compiler are you using? The default compiler on OSX 10.2 should  
> be gcc 3.1, and that allows "C++ style" declarations, GCC 2.95  
> doesn't. You can check the default compiler using 'gcc_select'.
>
> Ronald
>

Re: [Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Ronald O. <ous...@ci...> - 2003-07-05 19:48:54

On Saturday, 5 July, 2003, at 21:38, Bill Dozier wrote:

> Ronald,
>
> this is confusing:
>
> [gigabook:~/build/pyobjc-1.0b1] daddy% which gcc
> /usr/bin/gcc
> [gigabook:~/build/pyobjc-1.0b1] daddy% gcc -v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
> [gigabook:~/build/pyobjc-1.0b1] daddy%
> [gigabook:~/build/pyobjc-1.0b1] daddy% gcc_select
> Current default compiler:
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
> [gigabook:~/build/pyobjc-1.0b1] daddy%

This looks good. Except for the version of gcc, GCC claims to be 3.1 on  
my system. You aren't using pre-elease software are you? ;-) ;-)

>
>
> However, PB only gives 2.95 and 3.1 as choices (3.1 is selected).
>
> In the build window, though:
>
> /Developer/Private/jam -d1 -j1  
> JAMBASE=/Developer/Makefiles/pbx_jamfiles/ProjectBuilderJambase  
> JAMFILE=- build ACTION=build _DEFAULT_GCC_VERSION=2.95.2  
> BUILD_STYLE=Development  
> CPP_HEADERMAP_FILE=/Users/daddy/Desktop/pydoctest/build/ 
> pydoctest.build/pydoctest.build/pydoctest.hmap  
> SRCROOT=/Users/daddy/Desktop/pydoctest  
> OBJROOT=/Users/daddy/Desktop/pydoctest/build  
> SYMROOT=/Users/daddy/Desktop/pydoctest/build  
> DSTROOT=/tmp/pydoctest.dst

That is odd, this seems to indicate that PB actually uses gcc 2.95.

> I am neither a PB nor a jam expert.  Where is _DEFAULT_GCC_VERSION set?

Me neither, I hadn't even heard of jam before. I don't use PB very  
often, maybe one of the others can help out.

Ronald

Re: [Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Ronald J. <ro...@ma...> - 2003-07-05 19:49:14

For each target you have, under Settings/Expert View you should add   
two entries to "Build Settings":
CC = /usr/bin/gcc-3.3 and CPLUSPLUS=/usr/bin/g++-3.3
/mvh
Ronald

On Saturday, July 5, 2003, at 09:38 PM, Bill Dozier wrote:

> Ronald,
>
> this is confusing:
>
> [gigabook:~/build/pyobjc-1.0b1] daddy% which gcc
> /usr/bin/gcc
> [gigabook:~/build/pyobjc-1.0b1] daddy% gcc -v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
> [gigabook:~/build/pyobjc-1.0b1] daddy%
> [gigabook:~/build/pyobjc-1.0b1] daddy% gcc_select
> Current default compiler:
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
> [gigabook:~/build/pyobjc-1.0b1] daddy%
>
>
> However, PB only gives 2.95 and 3.1 as choices (3.1 is selected).
>
> In the build window, though:
>
> /Developer/Private/jam -d1 -j1  
> JAMBASE=/Developer/Makefiles/pbx_jamfiles/ProjectBuilderJambase  
> JAMFILE=- build ACTION=build _DEFAULT_GCC_VERSION=2.95.2  
> BUILD_STYLE=Development  
> CPP_HEADERMAP_FILE=/Users/daddy/Desktop/pydoctest/build/ 
> pydoctest.build/pydoctest.build/pydoctest.hmap  
> SRCROOT=/Users/daddy/Desktop/pydoctest  
> OBJROOT=/Users/daddy/Desktop/pydoctest/build  
> SYMROOT=/Users/daddy/Desktop/pydoctest/build > DSTROOT=/tmp/pydoctest.dst
>
> ...
>
> BuildPhase <CopyResources>pydoctest.app
>
> CompileC  
> /Users/daddy/Desktop/pydoctest/build/pydoctest.build/pydoctest.build/ 
> Objects-normal/ppc/bin-python-main.o
>     /usr/bin/gcc2  -c -F/Users/daddy/Desktop/pydoctest/build   
> -I/Users/daddy/Desktop/pydoctest/build/include  -arch ppc -fno-common  
> -fpascal-strings -O0 -Wmost -Wno-four-char-constants  
> -Wno-unknown-pragmas -pipe -g -precomp-trustfile  
> /Users/daddy/Desktop/pydoctest/build/pydoctest.build/pydoctest.build/ 
> TrustedPrecomps.txt  
> -Wp,-header-mapfile,/Users/daddy/Desktop/pydoctest/build/ 
> pydoctest.build/pydoctest.build/pydoctest.hmap       bin-python-main.m  
>  -o  
> /Users/daddy/Desktop/pydoctest/build/pydoctest.build/pydoctest.build/ 
> Objects-normal/ppc/bin-python-main.o
>
>
> I am neither a PB nor a jam expert.  Where is _DEFAULT_GCC_VERSION set?
>
> Thanks,
> Bill
>
>
> On Saturday, July 5, 2003, at 02:26 PM, Ronald Oussoren wrote:
>
>>
>> On Saturday, 5 July, 2003, at 20:43, Bill Dozier wrote:
>>
>>> Hi All,
>>>
>>> bin-python-main.m  does not compile. There are errors due to  
>>> variables not being declared early enough.
>>>
>>> Does this code compile for anyone else? I'd love to be able to  
>>> declare variables later, C++ style, if obj-c can allow it.
>>
>> What compiler are you using? The default compiler on OSX 10.2 should  
>> be gcc 3.1, and that allows "C++ style" declarations, GCC 2.95  
>> doesn't. You can check the default compiler using 'gcc_select'.
>>
>> 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/psa00100006ave/direct;at.asp_061203_01/ 
> 01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Bill D. <wdd...@ma...> - 2003-07-05 20:07:44

Cool. That works.

Where did the 2.95 default setting come from? Isn't there a place to 
set this globally?

Thanks!

On Saturday, July 5, 2003, at 02:49 PM, Ronald Jaramillo wrote:

> For each target you have, under Settings/Expert View you should add  
> two entries to "Build Settings":
> CC = /usr/bin/gcc-3.3 and CPLUSPLUS=/usr/bin/g++-3.3

Re: [Pyobjc-dev] doc-based project, bin-python-main.m does not compile

From: Ronald J. <ro...@ma...> - 2003-07-05 20:20:49

> Where did the 2.95 default setting come from?

GCC 3.3 is the default ( if you installed the latest update), PB is the 
only one who is not aware of it. It defaults to 3.1 and when the system 
tells it that 3.1 is not the default anymore, it use 2.95 = (.

>  Isn't there a place to set this globally?

Don't know, maybe configuring the PB templates?
Dough it's easy to revert to 3.1 in bash do #gcc_select  3 (  to go 
back to 3.3 #gcc_select 3.x )

>
> Thanks!

You are wellcome
=)

Re: [Pyobjc-dev] cvs snapshots?

From: Ronald O. <ous...@ci...> - 2003-07-01 19:39:00

What's the easiest way to automaticly make these snapshots? I could  
write a script that does a 'cvs export' and creates a tarball of the  
result, but I'm not sure if that is the best way to deal with this.

Ronald

On Tuesday, Jul 1, 2003, at 19:43 Europe/Amsterdam, Michael Hudson  
wrote:

> Given SF's current attitude to anon CVS, is it possible to make
> available snapshots of the state of CVS semi-regularly?
>
> Cheers,
> M.
>
> --  
>   ARTHUR:  Don't ask me how it works or I'll start to whimper.
>                    -- The Hitch-Hikers Guide to the Galaxy, Episode 11
>
>
>
> -------------------------------------------------------
> 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/psa00100006ave/direct;at.asp_061203_01/ 
> 01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] cvs snapshots?

From: Just v. R. <ju...@le...> - 2003-07-01 20:17:10

Attachments: snapshot.py

Ronald Oussoren wrote:

> What's the easiest way to automaticly make these snapshots? I could  
> write a script that does a 'cvs export' and creates a tarball of the  
> result, but I'm not sure if that is the best way to deal with this.

Here's what I use (needs editing, the configuration is in the code!).
It's from a guy named Eric Sunshine, the output is way more elaborate
than what I needed, but it does the job just fine.

Just