Re: DYLD_ALLOW_MULTISYMS

[Kevin Michael Vail]

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

> I *know* I'm missing something, I just don't know what.

OK, thanks to Rick and Jerry for pointing out that what I was missing 
was the boat.  ;-)  I remembered too far back.  DYLD_ALLOW_MULTISYMS is 
out, patches to Tk/MMUtil.pm is in.

Now if I can just put this somewhere where I'll remember it next time.  
Can't be my brain, I need something that'll keep it secure.

Thanks, all!
-- 
Kevin Michael Vail | Dogbert: That's circular reasoning.
[EMAIL PROTECTED]   | Dilbert: I prefer to think of it as no loose ends.
http://www.vaildc.net/kevin/

Re: Apple Perl directory layout

[Wilfredo Sánchez]

  Not related.  I caved in after getting hammered with protests for the 
Nth time via email for the horrible and evil decision I made way back 
when, not to version the directories.  :-)

  For what it's worth, my logic back then was:

  As pointed out here, if Apple upgrades perl, you have probably to 
upgrade XS modules.  But what I was thinking was that there might be an 
application which embeds perl and therefore links against the perl 
library.  A new system update with a new perl may require that 
application to relink as well, if it uses API that changed in perl.  
However, if the API was compatible, the app could continue to work.  
This will never work, however, if the perl library moved location, as 
that will cause a linker failure at runtime.  So my theory was that 
breaking less often would be a good thing.

  Anyway, this can still be done with symlinks, and perhaps that's a 
more flexible way to do it.

	-wsv


On Monday, December 9, 2002, at 12:05  PM, Christopher D. Lewis wrote:

I did file a bug via http://www.apple.com/macosx/feedback and 
subsequently, wsanchez apparently submitted a perl patch which leads 
to version-numbers in the pathname.
	--Chris

Re: Upgrade Mac::Carbon problems

[Emmanuel. M. Decarie]

I'm on the digest, so I'm pasting this from the web archive at
.


À (At) 11:38 -0500 16/12/02, Chris Nandor écrivait (wrote) :

In article ,
  [EMAIL PROTECTED] (Emmanuel. M. Decarie) wrote:

 >

  ¿ (At) 18:07 -0500 14/12/02, Chris Nandor Ècrivait (wrote) :
  >Could you search your system headers for "keyReplyPortAttr"?


 >  > Hmm, not sure what you are saying here. I just know basic C and I'm

  not familiar with the Carbon framework. Where are my system headers?


  > I tried that though:


  % grep -r "keyReplyPortAttr"  /System/Library/Frameworks/*

  But it take forever to run. If you give me more details, I'll try again.


Yes, it could take forever.  :-)  I am not sure how to better narrow it
down, though.  Maybe use find(1) to look for *.h files.


Ok, I'll see what I can do.


Ok, I used this in /System/Library/Frameworks without results:

% find . -name "*.h" -type f -exec  grep -i "keyReplyPortAttr" {} \;


À (At) 11:38 -0500 16/12/02, Chris Nandor écrivait (wrote) :
 > >Weird.  Are you sure you clicked Cancel?
 >
 > I think so, but I have no proofs of it :)

Oops, wrong test.  In this one you needed to select the number "3" from the
list.  Could you try again?  :-)


Oh my God, its possible that I didn't understand the question. Thanks
for giving me the answer :).

Ok, I'm running this test now from Terminal.app. To be sure that we
are talking of the same thing, this test is run in a folder called
"Mac-Carbon-0.02_01" with the mod noted in a previous email in
Carbon.h.

I noted this when I do 'make' and it comes back a lot of time:

/usr/include/gcc/darwin/2.95.2/g++/../stdbool.h:10: warning: empty declaration

Ok, the result of the tests look good:

All tests successful, 2 subtests skipped.
Files=13, Tests=85, 94 wallclock secs (17.43 cusr +  3.97 csys = 21.40 CPU)

But what is odd, is that I heard the beeps, but no speech and roar
like the other time. That was the best part of the tests. Its
possible that the sound level didn't came back to be audible. Before
the tests, I was listening some music with iTunes, and after the
test, I had to lower up the sound level because I could'nt hear a
thing.


 > >  > Processes/t/Processes..ok
 > >>   2/6 skipped: No parent
 > >
 > >Odd.  You ran this on the local machine from Terminal.app?
 >
 > No I'm using GLterm. Terminal is not very user good on OS X 10.1.5. I
 > hope it get better on Jaguar.

OK, good.  This is an X11 terminal app?  It doesn't "work" for me either,
with xterm.  I don't know if there is a way to use this method from an X11
terminal, so I won't worry about it, and allow the tests to be skipped.


No, GLTerm is a native OS X app that use OpenGL for drawing text.



Cheers
-Emmanuel


--
__
Emmanuel Décarie / Programmation pour le Web - Programming for the Web
Frontier - Perl - PHP - Javascript - XML  

Re: The "Inside Macintosh" warning still valid for Mac::Carbon?

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Ken Williams) wrote:

> In the documentation for modules like Mac::Resources and Mac::Memory, 
> there's always a warning that says I need to look at "Inside Macintosh", 
> and reminds me that this has been a Warning.  Is the material from IM 
> now part of the documentation in /Developer/Documentation/ ?  If so, it 
> would be nice if it were pointed out, as I'm not exactly sure where to 
> look for the docs on a lot of this stuff.

It's still valid.  I suppose one could append "and/or the Carbon 
documentation and headers."  Inside Macintosh is not included in the 
/Developer/ docs that I know about, but it is far more complete than the 
Carbon docs, in terms of explaining and covering each function, constant, 
etc.  OTOH, the Carbon docs (and, more importantly, the headers, which are 
much better than the docs in /Developer/) say what changes / additions / 
removals have been made to the existing API.


> Also, it looks like the '=include *.xs' directives didn't get processed 
> for the binary installer of Mac::Carbon 0.02, so some of the docs are 
> missing there too.

That's fixed in 0.02_01.

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

Re: Apple Perl directory layout

[Sherm Pendley]

On Tuesday, December 17, 2002, at 02:54 AM, Wilfredo Sánchez wrote:


what I was thinking was that there might be an application which embeds 
perl and therefore links against the perl library.  A new system update 
with a new perl may require that application to relink as well, if it 
uses API that changed in perl.  However, if the API was compatible, the 
app could continue to work.

You were right. The CamelBones framework is linked against libperl, and 
I've received numerous reports that CB apps continue to work untouched 
after an upgrade to 5.6.1, which is binary-compatible.

sherm--

If you listen to a UNIX shell, can you hear the C?

Re: Apple Perl directory layout

[Dan Sugalski]

At 11:54 PM -0800 12/16/02, Wilfredo Sánchez wrote:


  As pointed out here, if Apple upgrades perl, you have probably to
upgrade XS modules.  But what I was thinking was that there might be
an application which embeds perl and therefore links against the
perl library.  A new system update with a new perl may require that
application to relink as well, if it uses API that changed in perl.
However, if the API was compatible, the app could continue to work.
This will never work, however, if the perl library moved location,
as that will cause a linker failure at runtime.  So my theory was
that breaking less often would be a good thing.


It's important to note that the directory structure was *not* meant
to deal with this sort of problem. What it was meant for was to
provide the ability to have multiple versions of perl installed
simultaneously as a means of preventing breakage. Once you linked
against, say, 5.6.0, you just kept 5.6.0 around, rather than trusting
that 5.6.1 (or 5.8.0) behaved the same as the version you were
replacing.

Perl didn't really have embedding in mind when that dir structure was
set--it's more targeted at extensions, and the assumption has always
been that embedders link against an explicit versioned libperl
library.

We're going to fix this for perl 6... ;)
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Apple Perl directory layout

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Sherm Pendley) wrote:

> You were right. The CamelBones framework is linked against libperl, and 
> I've received numerous reports that CB apps continue to work untouched 
> after an upgrade to 5.6.1, which is binary-compatible.

An excellent reason to tell people to put perl in /usr/local/ (or similar)!

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

Mac::Carbon 0.03 Released

[Chris Nandor]

Mac::Carbon 0.03 is on the CPAN (er, on its way there, anyway) and 
SourceForge.net.

   http://sf.net/projects/macperl/
   http://www.cpan.org/authors/id/C/CN/CNANDOR/

It fixes the bugs with AEDesc, POD, xsubpp, building on Mac OS X 
10.1/gcc2/etc.  A binary distribution for perl 5.6 is available from 
SourceForge.net.  Thanks to all who have helped, and please submit bugs to 
SourceForge.net if you have any to report.

This is the last release for a little while; I am going to focus on fixing 
some of the outstanding bugs listed in the documentation.  Patches welcome.  
Enjoy!

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