pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Re: A question of concience

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

In article <a05200a18bb30d40d2839@[10.0.1.2]>,
 "Frans H. Schippers" <Fra...@xs...> wrote:

> +1 on the breakage.
> I agree with Just. I a function that would break,
> but no problem, a few minutes work.

I agree with Just and Frans.  Better to get this right now than delay it 
and make it more painful to change later.

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

[Pyobjc-dev] GNUstep support

[David B. <te...@bi...>]

Going with the assumption that I will get PyObjC working decently on my lap=
top=20
(can't try out the suggestions until tonight), I'm now trying to get it up=
=20
and going on my linux box.

After installing the python-dev packages, running python setup.py --help=20
produced the following:

<snip build of libffi that worked>
Performing task: Generating wrappers & stubs
sh: line 1: /usr/bin/sw_vers: No such file or directory
Traceback (most recent call last):
  File "Scripts/CodeGenerators/cocoa_generator.py", line 32, in ?
    VER =3D '.'.join(VER.split('.')[:2])
AttributeError: 'NoneType' object has no attribute 'split'
Task 'Generating wrappers & stubs' failed [256]

Now, 'locate sw_vers' produced nothing, as did 'apt-cache search sw_vers', =
so=20
I went to Google.  Every hit on sw_vers had to do with OSX, so can I safely=
=20
assume that it is not available in linux/GNUstep?  Maybe (really reading=20
between the lines here), it should be calling uname instead?  I *did* read=
=20
somewhere (in a changelog? maybe?) that GNUstep support was being removed=20
until a volunteer was found, so if necessary, take this as me stepping=20
forward...

Relevant (?) information:

Debian/Sid on i386
Python 2.2
GNUstep 1.6.0/0.8.5
GCC (objc) 3.3
Libra

P.S.  I went ahead and signed up to the list, so any replies need not cc: m=
e. =20
Same goes for the other thread, but whatever...

=2D-=20
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop

Re: [Pyobjc-dev] A question of concience

[Frans H. S. <Fra...@xs...>]

>Ronald Oussoren wrote:
>
>> There is one problem with this change: backward compatibility. If
>> we'd apply this change, we might break code that currently uses
>> methods like getNumberOfRows:columns:. The current users might also
>> use code that wouldn't break, like this:
>>   rows, cols = obj.getNumberOfRows_columns_()[1:]
>>
>> I'd rather not break backward compatibility, but this change would
>> increase the useability of PyObjC. Any opinions?
>
>+1 on the breakage. Hey, we're only at 1.0b1 ;-) The fact we didn't hear
>complains about this before seems to indicate these kinds of methods
>aren't being used much yet.
>
>Just
>

+1 on the breakage.
I agree with Just. I a function that would break,
but no problem, a few minutes work.

Frans
-- 
X|support bv               mailto:fra...@xs...
Grote Beer 189             http://www.xsupport.nl
1188 AZ Amstelveen         tel: +31 20 4411 258
ING 6533.74.208 Amstelveen fax: +31 23 5424 282                 
			   mbl: +31 653 650 806
KvK  33301359 Amstelveen   btw: NL-807284324B01

Re: [Pyobjc-dev] A question of concience

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

Ronald Oussoren wrote:

> There is one problem with this change: backward compatibility. If
> we'd apply this change, we might break code that currently uses
> methods like getNumberOfRows:columns:. The current users might also
> use code that wouldn't break, like this:
>   rows, cols = obj.getNumberOfRows_columns_()[1:]
> 
> I'd rather not break backward compatibility, but this change would 
> increase the useability of PyObjC. Any opinions?

+1 on the breakage. Hey, we're only at 1.0b1 ;-) The fact we didn't hear
complains about this before seems to indicate these kinds of methods
aren't being used much yet.

Just

Re: [Pyobjc-dev] PyObjc speed

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

On Tuesday, July 8, 2003, at 2:42 PM, Just van Rossum wrote:
> (thinking out loud) I think that for 2.3 we should make a special
> (Objective-)C main program that takes over the bootstrap stuff, is
> linked against Cocoa and Python.framework, and does not do the
> os.execve() trick. It can look up additional info in the Info.plist 
> file
> (like, what Python main program to execute). I think it wouldn't be all
> that unlike Bill's bin-python-main.m. It won't have to be compiled 
> every
> time, we can ship it with a binary distro so we're still able to build
> apps without the dev tools.

Just look in the attic... ;-) Web Services Tool originally used an 
embedded interpreter.

And it does again -- the project templates should be updated, at some 
point.  You can actually have a single template covering both cases, 
but it make project administration somewhat of a bear.

[Pyobjc-dev] A question of concience

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

In a private conversation Dan Grassi mentioned that methods like the 
one below are transformed into Python methods in an unexpected way. 
Specifically:

	-(void)getNumberOfRows:(int*)rowCount columns:(int*)columnCount; // 
both are output parameters

is translated into
	getNumberOfRows_columns_(self) -> (None, rowCount, columnCount)

He expected that the result would be (rowCount, columnCount).

I think he has a point. The current translation is the result of 
applying the basic rule a little too strictly. The basic rule says: The 
return value of methods with output arguments is a tuple containing the 
original return value, followed by the values of all output arguments 
in order. A return type of 'void' is usually translated into a method 
returning None, and therefore the return value for the method mentioned 
above is a tuple with None as its first element (the original return 
value).

Just ignoring the original return value if this is always void would be 
more usefull, as a method returning void is a method that does *not* 
return a value when viewed as an Objective-C method. This would make 
the translation of getNumberOfRows:columns: more natural.

There is one problem with this change: backward compatibility. If we'd 
apply this change, we might break code that currently uses methods like 
getNumberOfRows:columns:. The current users might also use code that 
wouldn't break, like this:
	rows, cols = obj.getNumberOfRows_columns_()[1:]

I'd rather not break backward compatibility, but this change would 
increase the useability of PyObjC. Any opinions?

Ronald

Re: [Pyobjc-dev] PyObjc speed

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

Ronald Oussoren wrote:

> +1 from me.
> 
> If linking with Cocoa and Carbon is not too expensive we might even
> do that, and try to sell the idea to Jack as a genericly usefull
> thing for MacPython :-)

Yeah, it could almost be the generic main program. But ideally it should
look in the Info.plist file which Python program to execute. That's an
option for Python.app (as embedded inside Python.framework).

Just

Re: [Pyobjc-dev] PyObjc speed

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

On Tuesday, 8 July, 2003, at 20:42, Just van Rossum wrote:
> (thinking out loud) I think that for 2.3 we should make a special
> (Objective-)C main program that takes over the bootstrap stuff, is
> linked against Cocoa and Python.framework, and does not do the
> os.execve() trick. It can look up additional info in the Info.plist 
> file
> (like, what Python main program to execute). I think it wouldn't be all
> that unlike Bill's bin-python-main.m. It won't have to be compiled 
> every
> time, we can ship it with a binary distro so we're still able to build
> apps without the dev tools.

+1 from me.

If linking with Cocoa and Carbon is not too expensive we might even do 
that, and try to sell the idea to Jack as a genericly usefull thing for 
MacPython :-)

Ronald

Re: [Pyobjc-dev] PyObjc speed

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

On Tuesday, 8 July, 2003, at 20:29, Bob Ippolito wrote:

> On Tuesday, Jul 8, 2003, at 14:04 America/New_York, Ronald Oussoren 
> wrote:
>
>>
>> On Tuesday, 8 July, 2003, at 17:40, b.bum wrote:
>>
>>> The problem is a result of the lack of a library with which to embed 
>>> the Python 2.2. interpreter on OS X 10.2.    If you build and 
>>> install the framework version of Python 2.3b1 and use an embedded 
>>> interpreter, the launch times drop significantly.
>>>
>>> Launching a PyObjC app will always be a bit slower because of the 
>>> additional pieces that must be initialized, but not 3x slower!
>>
>> One of the problems we're having, and why an embedded interpreter is 
>> much faster, is that the Foundation and AppKit frameworks get 
>> dynamicly loaded. This means preloading doesn't work, which in turn 
>> means much slower loading. If anyone knows how to make sure 
>> preloading works with Python modules please tell us, that would be 
>> really helpfull.
>>
>> Jack has experimented with a /usr/local/bin/python that has been 
>> linked with AppKit and that caused much faster loading of PyObjC. 
>> This won't make it into the 2.3 release because it is unclear what 
>> the side effects of linking with AppKit are. We want to be 100% sure 
>> that /usr/local/bin/python runs without access to the WindowServer.
>
> It's a pretty safe bet that unless Apple changes WindowServer and/or 
> LaunchServices significantly, no binary will ever have legitimate 
> access to WindowServer *unless* argv[0] points to the inside of a 
> valid bundle (either though normal exection or execve).. nomatter what 
> you link to and when.

That's why we have to be carefull. If there's any initialization code 
in AppKit that requires access to the WindowServer we'd be hosed if the 
python interpreter were linked with AppKit.

Ronald

Re: [Pyobjc-dev] PyObjc speed

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

Ronald Oussoren wrote:

> One of the problems we're having, and why an embedded interpreter is
> much faster, is that the Foundation and AppKit frameworks get
> dynamicly loaded. This means preloading doesn't work, which in turn
> means much slower loading. If anyone knows how to make sure
> preloading works with Python modules please tell us, that would be
> really helpfull.
> 
> Jack has experimented with a /usr/local/bin/python that has been
> linked with AppKit and that caused much faster loading of PyObjC.
> This won't make it into the 2.3 release because it is unclear what
> the side effects of linking with AppKit are. We want to be 100% sure
> that 
> /usr/local/bin/python runs without access to the WindowServer.

(thinking out loud) I think that for 2.3 we should make a special
(Objective-)C main program that takes over the bootstrap stuff, is
linked against Cocoa and Python.framework, and does not do the
os.execve() trick. It can look up additional info in the Info.plist file
(like, what Python main program to execute). I think it wouldn't be all
that unlike Bill's bin-python-main.m. It won't have to be compiled every
time, we can ship it with a binary distro so we're still able to build
apps without the dev tools.

Just

Re: [Pyobjc-dev] PyObjc speed

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

On Tuesday, Jul 8, 2003, at 14:04 America/New_York, Ronald Oussoren 
wrote:

>
> On Tuesday, 8 July, 2003, at 17:40, b.bum wrote:
>
>> The problem is a result of the lack of a library with which to embed 
>> the Python 2.2. interpreter on OS X 10.2.    If you build and install 
>> the framework version of Python 2.3b1 and use an embedded 
>> interpreter, the launch times drop significantly.
>>
>> Launching a PyObjC app will always be a bit slower because of the 
>> additional pieces that must be initialized, but not 3x slower!
>
> One of the problems we're having, and why an embedded interpreter is 
> much faster, is that the Foundation and AppKit frameworks get 
> dynamicly loaded. This means preloading doesn't work, which in turn 
> means much slower loading. If anyone knows how to make sure preloading 
> works with Python modules please tell us, that would be really 
> helpfull.
>
> Jack has experimented with a /usr/local/bin/python that has been 
> linked with AppKit and that caused much faster loading of PyObjC. This 
> won't make it into the 2.3 release because it is unclear what the side 
> effects of linking with AppKit are. We want to be 100% sure that 
> /usr/local/bin/python runs without access to the WindowServer.

It's a pretty safe bet that unless Apple changes WindowServer and/or 
LaunchServices significantly, no binary will ever have legitimate 
access to WindowServer *unless* argv[0] points to the inside of a valid 
bundle (either though normal exection or execve).. nomatter what you 
link to and when.

Even still, regardless of how the binary was executed, it is possible 
to hijack WindowServer support at runtime (assuming the user would 
otherwise have access to WindowServer) if you know which magic private 
api function to call.

-bob

Re: [Pyobjc-dev] PyObjc speed

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

On Tuesday, 8 July, 2003, at 17:40, b.bum wrote:

> The problem is a result of the lack of a library with which to embed 
> the Python 2.2. interpreter on OS X 10.2.    If you build and install 
> the framework version of Python 2.3b1 and use an embedded interpreter, 
> the launch times drop significantly.
>
> Launching a PyObjC app will always be a bit slower because of the 
> additional pieces that must be initialized, but not 3x slower!

One of the problems we're having, and why an embedded interpreter is 
much faster, is that the Foundation and AppKit frameworks get dynamicly 
loaded. This means preloading doesn't work, which in turn means much 
slower loading. If anyone knows how to make sure preloading works with 
Python modules please tell us, that would be really helpfull.

Jack has experimented with a /usr/local/bin/python that has been linked 
with AppKit and that caused much faster loading of PyObjC. This won't 
make it into the 2.3 release because it is unclear what the side 
effects of linking with AppKit are. We want to be 100% sure that 
/usr/local/bin/python runs without access to the WindowServer.

Ronald

Re: [Pyobjc-dev] PyObjc speed

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

The problem is a result of the lack of a library with which to embed 
the Python 2.2. interpreter on OS X 10.2.    If you build and install 
the framework version of Python 2.3b1 and use an embedded interpreter, 
the launch times drop significantly.

Launching a PyObjC app will always be a bit slower because of the 
additional pieces that must be initialized, but not 3x slower!

b.bum

On Tuesday, July 8, 2003, at 10:40 AM, David Bishop wrote:

> [sorry, forgot to mention that I'm not signed up to the list, so 
> please cc: me
> on any replies]
>
> After seeing the announcement for PyObjc on the cocoa-dev list, I 
> decided to
> download and try it out.  Unfortunetly, I think (hope!) I'm doing 
> something
> wrong.  I have a 300Mhz iBook with 284 Megs of ram.  It isn't a speed 
> demon,
> but Jaguar runs fine on it.  However, when using a brand-new 
> Python/Cocoa
> project (the template), it takes *20* seconds to startup.  In 
> comparasion PB
> takes about 5.  If I run the program, then kill it and immediately 
> launch it
> again, it drops to 18 seconds.  Either one is way too long to be 
> usable.  Any
> ideas of what I should try?  Some sort of pre-compile?  Use MacPython 
> rather
> than the built-in 2.2?  I can appreciate that it will not be as fast as
> ObjC/Cocoa app, but...
>
> Many thanks!
>
> -- 
> "Sorry about the whole 'bomb' thing" - Bruce Rollins
> D.A.Bishop
>
>
> <mime-attachment>

[Pyobjc-dev] PyObjc speed

[David B. <te...@bi...>]

[sorry, forgot to mention that I'm not signed up to the list, so please cc:=
 me=20
on any replies]

After seeing the announcement for PyObjc on the cocoa-dev list, I decided t=
o=20
download and try it out.  Unfortunetly, I think (hope!) I'm doing something=
=20
wrong.  I have a 300Mhz iBook with 284 Megs of ram.  It isn't a speed demon=
,=20
but Jaguar runs fine on it.  However, when using a brand-new Python/Cocoa=20
project (the template), it takes *20* seconds to startup.  In comparasion P=
B=20
takes about 5.  If I run the program, then kill it and immediately launch i=
t=20
again, it drops to 18 seconds.  Either one is way too long to be usable.  A=
ny=20
ideas of what I should try?  Some sort of pre-compile?  Use MacPython rathe=
r=20
than the built-in 2.2?  I can appreciate that it will not be as fast as=20
ObjC/Cocoa app, but...

Many thanks!

=2D-=20
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop

[Pyobjc-dev] PyObjc speed

[David B. <te...@bi...>]

After seeing the announcement for PyObjc on the cocoa-dev list, I decided t=
o=20
download and try it out.  Unfortunetly, I think (hope!) I'm doing something=
=20
wrong.  I have a 300Mhz iBook with 284 Megs of ram.  It isn't a speed demon=
,=20
but Jaguar runs fine on it.  However, when using a brand-new Python/Cocoa=20
project (the template), it takes *20* seconds to startup.  In comparasion P=
B=20
takes about 5.  If I run the program, then kill it and immediately launch i=
t=20
again, it drops to 18 seconds.  Either one is way too long to be usable.  A=
ny=20
ideas of what I should try?  Some sort of pre-compile?  Use MacPython rathe=
r=20
than the built-in 2.2?  I can appreciate that it will not be as fast as=20
ObjC/Cocoa app, but...

Many thanks!

=2D-=20
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop

Re: [Pyobjc-dev] RegexPlor demo (Was: PyObjC- vs. Python Unicode)

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

Very briefly... I've quite a bit updated this, more Panther-like now,
no movie yet, still have to include some day a feature to re-split:

   http://python.net/~gherman/tmp/RegexPlor1.jpg
   http://python.net/~gherman/tmp/RegexPlor.tar.gz

Enjoy,

Dinu

--
Dinu C. Gherman
......................................................................
"A whole generation has grown up with the idea that it is normal
for them to have no freedom." (Richard M. Stallman)

[Pyobjc-dev] MacUpdate Dev: PyObjC updated

[<mac...@ma...>]

the PyObjC team,

PyObjC 0.9 has just been updated to version 1.0b1 on MacUpdate. Check it out at:

http://www.macupdate.com/info.php/id/11709

Please keep MacUpdate informed of any new Mac version releases of your products, so we can promote them for you. You can update your listing by sending us an email or going to:

http://www.macupdate.com/email/submission.php

-Joel Mueller
www.macupdate.com

[You're being notified of this update because you're listed as the developer of PyObjC. Please email us if you are not the developer: mac...@ma...].

[Pyobjc-dev] ANN: PyObjC 1.0b1

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

PyObjC 1.0b1 is now available for download at 
http://pyobjc.sourceforge.net/

PyObjC is a bridge between Python and Objective-C.  It allows full
featured Cocoa applications to be written in pure Python.  It is also
easy to use other frameworks containing Objective-C class libraries
from Python and to mix in Objective-C, C and C++ source.

Python is a highly dynamic programming language with a shallow learning
curve.  It combines remarkable power with very clear syntax.

The installer package includes a number of Project Builder templates for
easily creating new Cocoa-Python projects, as well as support for
syntax-coloring Python files in Project Builder.

PyObjC also supports full introspection of Objective-C classes and
direct invocation of Objective-C APIs from the interactive interpreter.

PyObjC requires MacOS X 10.2 or later.  PyObjC works both with the Apple
provided Python installation in MacOS X 10.2 (and later) and with
MacPython 2.3b1.  Users of MacPython 2.3b1 can install PyObjC though the
PackageManager application.

PyObjC 1.0b1 includes numerous improvements over earlier versions, 
including:

* Improved performance and stability
* Better tutorials and examples
* Initial support for MacOS X 10.1
* Support for the WebKit framework
* Write plugin bundles in Python (requires Python 2.3b1)

PyObjC is released with an open source license.

NOTE: There has been a minor update to the packaging w.r.t. the 
pre-release of a couple of days ago. The binary package didn't change. 
You can download a new source tarball if you had problems compiling the 
bridge on systems with Safari 1.0.

Re: [Pyobjc-dev] Pre-ANN: PyObjC 1.0b1

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

On Monday, 7 July, 2003, at 00:02, Jack Jansen wrote:

>
> On zondag, jul 6, 2003, at 23:18 Europe/Amsterdam, Jack Jansen wrote:
>
>>
>> On zaterdag, jul 5, 2003, at 16:53 Europe/Amsterdam, Ronald Oussoren 
>> wrote:
>>
>>> I've uploaded the sources and a binary installer for PyObjC 1.0b1 to 
>>> SF. The official announcement will go out on Sunday, unless someone 
>>> finds a serious bug before then.
>>
>> I hope I'm not too late, but I think the dependency on the 
>> non-standard webkit stuff is
>> a major flaw. I download the source tarball, and it fails to compile 
>> without any
>> indication as to what is wrong. And we've gone through so much trouble
>> to add all our dependencies to the source distribution:-(
>
> Either I'm doing something stupid or the problem is worse than I 
> thought:
> there is no indication in the Install.txt or README.txt that you need 
> this WebKit thing,
> and moreover I cannot find it on the Apple developer site....

I'll fix this before sending out the final announcement. I'll mention 
the WebKit SDK in the readme or install.txt and I'll make sure the 
sources compile without WebKit.

Ronald

Re: [Pyobjc-dev] Pre-ANN: PyObjC 1.0b1

[Jim T. <jw...@On...>]

On Mon, Jul 07, 2003 at 12:02:16AM +0200, Jack Jansen wrote:
> this WebKit thing,
> and moreover I cannot find it on the Apple developer site....

Log in at https://connect.apple.com/ then navigate through
Download Software... WWDC 2003 and it is the bottom thing
on the page.  (Sorry, I don't think I can provide a directly
clickable link since the mercury FTP link seems to embed
my ADC member number and a hash of something that I assume
is my password.)

Re: [Pyobjc-dev] Pre-ANN: PyObjC 1.0b1

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

On zondag, jul 6, 2003, at 23:18 Europe/Amsterdam, Jack Jansen wrote:

>
> On zaterdag, jul 5, 2003, at 16:53 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> I've uploaded the sources and a binary installer for PyObjC 1.0b1 to 
>> SF. The official announcement will go out on Sunday, unless someone 
>> finds a serious bug before then.
>
> I hope I'm not too late, but I think the dependency on the 
> non-standard webkit stuff is
> a major flaw. I download the source tarball, and it fails to compile 
> without any
> indication as to what is wrong. And we've gone through so much trouble
> to add all our dependencies to the source distribution:-(

Either I'm doing something stupid or the problem is worse than I 
thought:
there is no indication in the Install.txt or README.txt that you need 
this WebKit thing,
and moreover I cannot find it on the Apple developer site....
--
- 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] Pre-ANN: PyObjC 1.0b1

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

On zaterdag, jul 5, 2003, at 16:53 Europe/Amsterdam, Ronald Oussoren 
wrote:

> I've uploaded the sources and a binary installer for PyObjC 1.0b1 to 
> SF. The official announcement will go out on Sunday, unless someone 
> finds a serious bug before then.

I hope I'm not too late, but I think the dependency on the non-standard 
webkit stuff is
a major flaw. I download the source tarball, and it fails to compile 
without any
indication as to what is wrong. And we've gone through so much trouble
to add all our dependencies to the source distribution:-(
--
- 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] more fun with pyobjc doc-based app project

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

On Saturday, 5 July, 2003, at 23:54, Bill Dozier wrote:

>
> Now that I have the compiler set correctly ;{>, if I build the pyobjc 
> doc-based project as-is and run it in the debugger I get a SIGTRAP 
> with this warning:  "warning: ppc_frame_chain_valid: stack pointer 
> from 0xbffff114 to 0x1000 grows upward; assuming invalid."
>
> I can just hit the continue button on the debugger and then things 
> continue, apparently OK.

I wouldn't be surpised if this is caused by the way we bootstrap 
applications. The bin-python-main.m file is only used to execute the 
python interpreter in /usr/bin/python (after setting up the right 
environment and arguments for the interpreter). I guess the debugger 
gets confused by this.

Ronald

[Pyobjc-dev] more fun with pyobjc doc-based app project

[Bill D. <wdd...@ma...>]

Now that I have the compiler set correctly ;{>, if I build the pyobjc 
doc-based project as-is and run it in the debugger I get a SIGTRAP with 
this warning:  "warning: ppc_frame_chain_valid: stack pointer from 
0xbffff114 to 0x1000 grows upward; assuming invalid."

I can just hit the continue button on the debugger and then things 
continue, apparently OK.

Bill

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

[Ronald J. <ro...@ma...>]

> 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
=)