So what's the status of PowerPlant source now?

Markus Dheus <mdheus RemoveThis @newsguy.com> wrote:

 > So the question is: Does anyone have any experiences with "Classic"
 > PowerPlant on XCode? How endian sensitive is Powerplant? I suppose it
 > would need some PPob wrangling, are there any more problem areas?

Following up my own message:

It appears that Apple provides some code for changing the endianness of
PPob data in

<http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi
nary/universal_binary_intro/chapter_1_section_1.html>

and there's documentation on what changes PowerPlant (CW8.3 version)
needs for XCode at

<http://developer.apple.com/documentation/DeveloperTools/Conceptual/Movi
ngProjectsToXcode/index.html>

So it looks the continuing support of PowerPlant Applications with XCode
(and x86) won't be a major hassle. That's a great relief.

It's sad to finally leave CodeWarrior for good. I've been using it since
DR2 on the Mac and later also used it for PalmOS and Windows
development, but it's now finally time to move on on all platforms.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

Markus Dheus <mdheus.TakeThisOut@newsguy.com> wrote:

  > > So the question is: Does anyone have any experiences with "Classic"
  > > PowerPlant on XCode? How endian sensitive is Powerplant? I suppose it
  > > would need some PPob wrangling, are there any more problem areas?
 >
 > Following up my own message:
 >
 > It appears that Apple provides some code for changing the endianness of
 > PPob data in
 >
 > <http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi
 > nary/universal_binary_intro/chapter_1_section_1.html>
 >
 > and there's documentation on what changes PowerPlant (CW8.3 version)
 > needs for XCode at
 >
 > <http://developer.apple.com/documentation/DeveloperTools/Conceptual/Movi
 > ngProjectsToXcode/index.html>
 >
 > So it looks the continuing support of PowerPlant Applications with XCode
 > (and x86) won't be a major hassle. That's a great relief.
 >
 > It's sad to finally leave CodeWarrior for good. I've been using it since
 > DR2 on the Mac and later also used it for PalmOS and Windows
 > development, but it's now finally time to move on on all platforms.

I too have a pet project in PowerPlant that I'll be migrating to x86.
It's been 95% Mach-O ready for at least two years, I just lacked the
final impetus to finish that off.

I've looked at Apple's document and posted my initial thoughts at
<http://www.sailmaker.co.uk/ubi_notes.html>.

I also make heavy use of the PowerPlant networking classes, and the
3rd-party WASTE wrappers. Both of those could be a lot of work. I might
be better off ditching them for CFSocket etc and ATSUI.

Apple's code for flipping ppob resources is all very well, but not
easily extensible to custom CTYPs. It's just a huge dumb switch
statement on CTYP with a default that prints to stderr and asserts.

A better approach, suggested to me by James W Walker, might be to
augment UReanimator and LStream with byte-swapping. That way,
everything would just work, provided authors of custom CTYPs have used
LStream properly in their constructor from LStream, i.e. using operator
  >> for each member, rather than inhaling a block of raw data and using
something like BlockMove or memcpy.

A lot can be done with zero changes to PowerPlant code, witness my
scroll wheel handler, but in this case I think some changes to
PowerPlant code will be necessary.

Whatever I do, I'll be sure to share it, even if all I can share is
diff files from a known baseline.

Of course, it would help enourmously if MW were to either (a) provide
some official mechanism for submitting and distributing changes to
PowerPlant code, or (b) simply bite the bullet and open-source it.

What do you say, MetroWerks? Will you do us one final favour and open
PowerPlant (and maybe PPx) to either controlled developer contribution
or full open-source?

Richard.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

On 08.06.2005 03:09, in article
080620050009461210%richardb@sailmaker.co.nospam.uk, "Richard Buckle"
<richardb.RemoveThis@sailmaker.co.nospam.uk> wrote:

 > I also make heavy use of the PowerPlant networking classes, and the
 > 3rd-party WASTE wrappers. Both of those could be a lot of work. I might
 > be better off ditching them for CFSocket etc and ATSUI.

WASTE is still very relevant; there's a beta of WASTE 3.0 which runs on
top of ATSUI. See <http://www.merzwaren.com/waste/we3_transition.html> for
details.

- WBR, Alexey Proskuryakov<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

Most of the structs that suck data out of PPobs are specific to a
particular control,
and not used elsewhere.

My suggestion would be to create C++ 'int' replacement types that do
the
byte-swapping automatically and support casting operators to native
integer types.

That's my plan, anyhoo.

Gen Kiyooka
Digigami
 >> Stay informed about: So what's the status of PowerPlant source now? 

For instance, here is a snippet that de-serializes an LBevelButton from
an LStream:

  SInt16 controlKind;
  ResIDT textTraitsID;
  *inStream >> controlKind;
  *inStream >> textTraitsID;

If we replace the SInt16 and ResIDT types in this function with C++
classes which
support integer type semantics and provide appropriate overrides for
the >> operator,
the byte-swapping can be done very easily. It's almost an non-issue.

Think C++

Gen Kiyooka
Digigami<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

I'm at WWDC and spoke briefly about open-sourcing PowerPlant classic
under a license that would work for Metrowerks.

If we can open it up, I, for one will have plenty of contributions.
I'm evolving classic powerplant for my own needs, and add support for
new OS features as I need them.

Also, there was a Quebec-based company that had a PP add-on commercial
library for awhile.

If we can get PowerPlant into a more community-oriented process, I
think it is a viable development framework. The design is remarkably
adaptable. Heck, we might even tap Greg Dow for some improvements.

Gen Kiyooka
digigami
 >> Stay informed about: So what's the status of PowerPlant source now? 

in article 1118251054.768176.73430 DeleteThis @z14g2000cwz.googlegroups.com, kiyookasan
at robohelp DeleteThis @yahoo.com wrote on 6/8/05 10:17 AM:

 > Also, there was a Quebec-based company

Cafederic.

 > that had a PP add-on commercial library for awhile.

BasePlant.

Since he dropped support from lack of sales, I imagine he'd probably be
willing to toss it into the ring. Andy Dent already said yesterday here
he'll put PP2MFC under any non-GPL license Metrowerks puts PowerPlant under.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

kiyookasan wrote:
 > Most of the structs that suck data out of PPobs are specific to a
 > particular control,
 > and not used elsewhere.
 >
 > My suggestion would be to create C++ 'int' replacement types that do
 > the
 > byte-swapping automatically and support casting operators to native
 > integer types.

What is your POV on the "flipper" code Apple provided for flipping data
in PPobs in their Universal Binary PDF?<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

In article <42a7f572$0$55316$e4fe514c@news.xs4all.nl>,
Arthur Langereis <arthur_extINVALID.DeleteThis@xfinitegames.com.tld> wrote:

 > kiyookasan wrote:
  > > Most of the structs that suck data out of PPobs are specific to a
  > > particular control, and not used elsewhere.
  > >
  > > My suggestion would be to create C++ 'int' replacement types that
  > > do the byte-swapping automatically and support casting operators to
  > > native integer types.
 >
 > What is your POV on the "flipper" code Apple provided for flipping data
 > in PPobs in their Universal Binary PDF?

The automatic swapping trick is useful; I've seen some code use it with
much success. A simpler option is to modify LStream to swap for you. A
third option is to use the flipper code, but even though I wrote a lot
of it, I think the first two options are probably cleaner for most
people.

-Eric

--
Eric Albert ejalbert.DeleteThis@cs.stanford.edu
<a style='text-decoration: underline;' href="http://outofcheese.org/" target="_blank">http://outofcheese.org/</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now? 

In article <ejalbert-C43AFB.02221410062005@localhost>,
Eric Albert <ejalbert RemoveThis @cs.stanford.edu> wrote:

 > In article <42a7f572$0$55316$e4fe514c@news.xs4all.nl>,
 > Arthur Langereis <arthur_extINVALID RemoveThis @xfinitegames.com.tld> wrote:
 >
  > > kiyookasan wrote:
   > > > Most of the structs that suck data out of PPobs are specific to a
   > > > particular control, and not used elsewhere.
   > > >
   > > > My suggestion would be to create C++ 'int' replacement types that
   > > > do the byte-swapping automatically and support casting operators to
   > > > native integer types.
  > >
  > > What is your POV on the "flipper" code Apple provided for flipping data
  > > in PPobs in their Universal Binary PDF?
 >
 > The automatic swapping trick is useful; I've seen some code use it with
 > much success. A simpler option is to modify LStream to swap for you. A
 > third option is to use the flipper code, but even though I wrote a lot
 > of it, I think the first two options are probably cleaner for most
 > people.
 >
 > -Eric

My apologies. If I had seen this posting first, I wouldn't have put in
my two cents in a different newsgroup.

--
David Phillip Oster<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: So what's the status of PowerPlant source now?