Re: Carbon patches for Mac::(Types,Memory,Resources)

2002-03-09 Thread Michael Blakeley

Chris Nandor wrote at 
:

>In article <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED] (Michael Blakeley) wrote:
>
>>  It's probably time that SourceForge had a Carbon Perl Modules
>>  project, feeding into CPAN.
>
>Yep!  One already exists.
>
>http://sf.net/projects/mac-carbon/

Ah - I searched on project names matching "perl" and missed it. No 
code in mac-carbon yet, but thanks for the pointer.

>  > Are the MacPerl developers still uninterested, as
>  > http://macperl.sf.net/ suggests?
>
>Why do you say we are uninterested?  The page clearly says the 
>opposite! Read again:
>
># It would be nice to, at some point, have the Toolbox modules
># (Mac::Windows, Mac::Events) Carbonized so the same GUI-based
># MacPerl programs would run on both platforms. This may happen in
># the future.

Yes, "uninterested" was the wrong word: "too busy" might have been 
more accurate. I'm not criticizing, please understand - I'm telling 
you why I decided to try this port myself.

I read the above text as saying "do it yourself if you want it so 
badly," in traditional open-source fashion :-). I read 
http:[EMAIL PROTECTED]/msg01197.html in the 
same vein. When developers tell me that they don't have time to work 
on a project, I take that as a broad hint that someone else has to 
step in, if it's going to happen.

Since I wanted it to happen, I gave it a few hours and got what I 
wanted (Mac::Resources on 10.1.3). Now I can run a crucial script on 
OSX, and I'm happy with that.

>The short story is that Matthias Neeracher has begun planning the
>Mac::Carbon module.  The plan is to port the existing Mac:: toolbox
>modules to use the new module, so they are primarily pure-perl 
>frontends to the new module.  I don't know if he's got any code 
>started yet, though I've stated that, as time permits, I want to 
>start working on it when MacPerl is released (any day now).

The approach you've outlined makes good sense.

So... it sounds to me like there's no place in this vision of 
Mac::Carbon for the patches that I've done, because Matthias is 
starting over with an empty CVS tree and h2xs. Is that correct?

That's ok with me - I just wanted to have Mac::Resources working for 
myself, and I've got that now. I'm going to leave my patches up at 
http://homepage.mac.com/mblakele/carbonperl/ and I may supplement 
them with a standalone tarball. If anyone wants to use them as a 
stop-gap until mac-carbon bears fruit, there they are.

Just for grins, I got Speech and Gestalt working this afternoon, just 
before seeing your message. Speech is pretty cool to have, and I may 
use it for error reports in a long-running command-line script that 
I've been working on. I expect that Controls, DCon, Fonts, MoreFiles, 
Notification, Processes, and SpeechRecognition would all be fairly 
easy to port as well (no XS_ functions, so the custom xsubpp isn't 
necessary, once the POD has been pulled out of the .xs files).

After that it would get more difficult, which makes me think that 
your mac-carbon approach is the right one.

-- Mike



Re: Carbon patches for Mac::(Types,Memory,Resources)

2002-03-09 Thread Chris Nandor

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Michael Blakeley) wrote:

> It's probably time that SourceForge had a Carbon Perl Modules 
> project, feeding into CPAN.

Yep!  One already exists.

   http://sf.net/projects/mac-carbon/


> But I'm a relative novice at XS, and even 
> more ignorant of Carbon, so I'm hoping that some more capable 
> developers will have time and interest, too. Are the MacPerl 
> developers still uninterested, as http://macperl.sf.net/ suggests?

Why do you say we are uninterested?  The page clearly says the opposite!  
Read again:

# It would be nice to, at some point, have the Toolbox modules
# (Mac::Windows, Mac::Events) Carbonized so the same GUI-based MacPerl
# programs would run on both platforms. This may happen in the future.

The fact is that we are very interested, and have already begun the 
process.

The short story is that Matthias Neeracher has begun planning the 
Mac::Carbon module.  The plan is to port the existing Mac:: toolbox 
modules to use the new module, so they are primarily pure-perl frontends 
to the new module.  I don't know if he's got any code started yet, 
though I've stated that, as time permits, I want to start working on it 
when MacPerl is released (any day now).  I know a lot of people want it, 
and I do too, so I want to get it going ASAP.

So all that said, I've not done any work on patches to the existing 
Mac:: modules for Carbon compatibility, since it looks like we're going 
a different way, as described above.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/



Carbon patches for Mac::(Types,Memory,Resources)

2002-03-09 Thread Michael Blakeley

I spent some time recently on Mac::Types, Mac::Memory, and 
Mac::Resources, and got all three to compile and pass minimal tests 
on 10.1.3 (OK, more than minimal: I'm now able to ditch MacPerl 
entirely for my last Carbon-dependent script). I've made patches 
available at
http://homepage.mac.com/mblakele/carbonperl/

These modules aren't incredibly useful except as a foundation for 
other modules, but I hope that these patches will help other 
interested perl-mongers to get started with Carbon-Perl projects.

It's probably time that SourceForge had a Carbon Perl Modules 
project, feeding into CPAN. But I'm a relative novice at XS, and even 
more ignorant of Carbon, so I'm hoping that some more capable 
developers will have time and interest, too. Are the MacPerl 
developers still uninterested, as http://macperl.sf.net/ suggests?

Here's a question for general discussion:

* should these modules continue to be known as Mac::Foo, so that we 
can aim for source portability between OS9 and OSX?

* or should they become Mac::Carbon::Foo so that the non-Carbon cruft 
can be removed?

* or should they become Carbon::Foo, in case Carbon ever makes it on 
non-Mac platforms?

Personally I lean toward the first option, since I have scripts that 
I'd like to be able to run on OS9 and OSX without modifications. 
Thoughts?

-- Mike